test plan:
1. go to /register
2. you should not be prompted to enter a birthdate in any of the flows
3. the forms should work
4. go to your (user) settings
5. you should not see your birthdate nor be able to enter one
6. the form should work
7. go to the self enrollment page for a course as a new user
8. you should not be prompted to enter a birthdate
9. the form should work
Change-Id: I9bf92d27e208696b2aed74b4a6396d434494679c
Reviewed-on: https://gerrit.instructure.com/18143
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
QA-Review: Cam Theriault <cam@instructure.com>
Separates, streamlines, and makes shard-aware all use cases of
User#messageable_users *other* than searching (call site in
SearchController#matching_participants).
Produces three new methods that take the bulk of that responsibility:
* User#load_messageable_users -- given a set of users, filter out the
ones that aren't messageable, and load any common contexts for those
that are.
* User#load_messageable_user -- as User#load_messageable_users, but for
just one user.
* User#messageable_users_in_context -- given a context (a course,
section, or group), return the list of messageable users in that
context.
refs CNVS-2519
remaining on CNVS-2519 is to tackle the search application of
User#messageable_user. mostly there, but reconciling pagination
with ranking by number of shared contexts is proving problematic, so I'm
going to separate that into another commit.
meanwhile, I've renamed User#messageable_users to
User#deprecated_search_messageable_users to discourage any accidental
new uses and left it otherwise untouched. searching for users on the
same shard should be unaffected. You can still locate messageable users
on other shards to insert into conversations by browsing the shared
contexts.
test-plan:
* create user A in shard X
* create user B in shard Y
* for situations where A could message B if on the same shard:
- setup the situation where the common tie is on shard X (e.g. course
on shard X and both A and B in it). run exercises below
- setup the situation where the common tie is on shard Y. run
exercises.
- if appropriate, setup the situation where the common tie is on
shard Z. run exercises.
* for each setup described above, login as A:
- A should see the "message this user" button on B's profile
- if the common tie is a course, section, or group, A should see B
under that context when the context is selected in the recipient
browser
- if a conversation exists involving both A and B, when A loads the
conversation they should see B tagged with the common contexts
* regression test searching for messageable users from the same shard
Change-Id: Ibba5551f8afc2435fd14a2e827a400bf95eae76a
Reviewed-on: https://gerrit.instructure.com/17569
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
The batch update runs in a background job and updates a
Progress record while it runs. Based on the recently added
course controller's batch_update method.
fixes CNVS-2962
test plan:
- read and check the api documentation for the conversations
batch_update call
- create some conversations for a user using the GUI
- use the new api call to perform batch updates on that user's
conversations
- refresh the user's inbox and verify the conversations were
updated properly.
Change-Id: I185bb5402675b6f0475efed21a525c5d4d8a39cb
Reviewed-on: https://gerrit.instructure.com/17556
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
Reviewed-by: Mark Ericksen <marke@instructure.com>
fixes CNVS-3606
Test plan:
* download some gradebook csv in a large class
* experience euphoria and surprise as your gradebook csv is quickly
delivered
Change-Id: I44e5fe14d73993d669eb6600072d6e2d125ad3cc
Reviewed-on: https://gerrit.instructure.com/17593
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Myller de Araujo <myller@instructure.com>
test plan
- create an assignment with no due date
- create a section override for the assignment with a due date
less than one week in the future
- as a student not in the overridden section, ensure that pages
that include the "Upcoming Assignment" list do not crash
Change-Id: I877fd8eabf31b68fb071903050ab3eb228050a70
Reviewed-on: https://gerrit.instructure.com/17520
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
fixes CNVS-1220
test plan
when checking for an assignment listed as upcoming, check:
- the "Coming Up" sidebar on the right of the user's or course's
"Recent Activity" page
- the "Upcoming Assignments" sidebar on the right of the user's
or course's Assignments page
- the "Upcoming Assignments" section on the main listing on the
user's or course's Assignments page
ensure assignments can be overridden to be upcoming
- create an assignment that is due more than one week from now
- as a student, ensure the assignment is not listed as upcoming
- create an override that applies to the student that makes the
assignment's due date less than one week from now
- As a student, ensure that the assignment is listed as upcoming
ensure assignments can be overridden to not be upcoming
- create an assignment that is due less than one week from now
- as a student, ensure the assignment is listed as upcoming
- create an override that applies to the student that makes the
assignment's due date more than one week from now
- As a student, ensure that the assignment is not listed as upcoming
Change-Id: Ia517d87f0a8ed48f6ce3ca466258e7ad8ebe650c
Reviewed-on: https://gerrit.instructure.com/17168
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Stanley Stuart <stanley@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
refs CNVS-1171
test plan:
* tags should show up and make sense when communicating with
someone in a different shard
Change-Id: I21da08d17740dafde766d368300d197897c3639b
Reviewed-on: https://gerrit.instructure.com/17082
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
fixes CNVS-2200
normalize ignores out of the users.preferences column into
its own table. makes it more performant, and shard safe
test plan:
* add a user as a teacher in courses on two different shards
* set up an assignment needing grading (i.e. have a student
submit an assignment that requires grading) in both courses
* the assignment should show up on the teacher's dashboard
regardless of which shard he's on
* ignore the assignment on your dashboard on one shard
* reload - it should stay gone
* it should also be gone on the other shard
* have another student submit to that assignment
* it should come back on both shards for the teacher
* ignore it, permanently this time
* have another student submit to that assignment
* it should still be gone on both shards
Change-Id: I6646410273c6be05d4b21b29b6ab76feb8e65d0f
Reviewed-on: https://gerrit.instructure.com/17295
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
fixes CNVS-1338
basically, just process associations for the current shard, unless
we're explicitly calling update_account_associations on just the user
(since all the other triggers will only affect associations within
the same shard)
test plan:
* enroll an existing site admin user from the default shard in to a
course on another shard
* the user should immediately show up in the course's account's user
list
* remove the user from the course
* the user should immediately disappear from the course's account's
user list
* note the associations a user has
(u.user_account_associations.with_each_shard)
* delete them all (u.user_account_associations.with_each_shard { |s|
s.delete_all })
* call u.update_account_associations
* make sure they all get recreated
Change-Id: I794363d1703fb2d46cd27b67b1216fedef4deaae
Reviewed-on: https://gerrit.instructure.com/17155
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
refs CNVS-1338
in preparation for calculating for multi-shard users
test plan:
* no visible change in behavior (in cases where the user doesn't
cross shards; this case will be defined and corrected in a
subsequent commit).
* things to regression test are that after adding a user to a course
in a sub account, they show up in the account; after removing them
from the course, they disappear from the account
Change-Id: Ie86d9dfa9978b42cb01503ace08a5fa6ea8638cc
Reviewed-on: https://gerrit.instructure.com/17141
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
fixes CNVS-1171
test plan:
* full conversations regression test
* initiate a conversation with a user from another shard
* reply to that conversation from both the sender and the
receiver
* repeat for a group conversation involving two or more
shards
* repeat for huge batch conversations with hundreds of
users and two or more shards
* known NOT working yet:
* re-using the correct cross-shard private conversation
* probably the tagging of messages with Course x,
Group y, etc.
Change-Id: I52549039875941cd518077cea4e28bfd2bc10dbf
Reviewed-on: https://gerrit.instructure.com/16523
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
refs CNVS-1338
test plan:
* run the migration on production-like data
* it should not fail
Change-Id: Ib8527f2cbee05d5e00941286f16c245091b1a2d9
Reviewed-on: https://gerrit.instructure.com/17117
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
refs #CNVS-1831
TEST PLAN:
1) no change in behavior, just a refactor
2) attempt to merge 2 users together
3) you should not suffer any surprise errors
during the user merge process
Change-Id: I8691b59e302dfda84dceeb890edafc54ade30c46
Reviewed-on: https://gerrit.instructure.com/16934
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
closes #CNVS-2464
test plan:
- turn self-enroll on for a course (course settings, more options)
- copy the secret URL
- turn self-enroll off
- go to the secret URL
- it should say enrollment is closed and not a 404 page
Change-Id: Ibd3f1c36f3c444dad48d4f492756d1db320475d8
Reviewed-on: https://gerrit.instructure.com/17226
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
QA-Review: Cam Theriault <cam@instructure.com>
fixes #CNVS-3432
stack traces were coming up in production with
the error "must be a root account".
granting the manage_logins permission on the
user model involved checking all user accounts
for subset permissions by loading up and then
examining all account users in every one of
a user's accounts, something that raises
an error in the account.rb model unless the accout
being examined is a root account. This
fix changes that permission check to only
examine root accounts, and also provides a
backup edge-case handler in
#has_subset_of_Account_permissions? which
just returns false if the account being examined
is not a root account.
TEST PLAN:
1) login as a local admin
2) go to the detail page for a user
within the context of an account, in particular
one where the user being examined is affiliated
with at least one non-root account:
example (https://wharton.instructure.com/accounts/81471/users/1189725)
3) you should not get any internal server errors,
and should be able to view the user's details.
Change-Id: I3a3995581bcc9bc7eb4074ea3f1ddeb66c598344
Reviewed-on: https://gerrit.instructure.com/17249
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
This commit fixes a regression from d30084, in which calls to
Api::V1::assignment_json were not being provided needed fields such as
'turnitin_settings' when accessed through the todos api. This caused the
instantiated ActiveRecord objects to throw an exception because the
field(s) had not been assigned.
test plan:
- Ensure you have a todo, e.g. an assignment that you haven't
submitted but is due in the future.
- Make an authenticated API request for todos
(e.g. /api/v1/users/self/todo ).
- The API response should be successful and include todo information.
The API response should not contain an error message, or have an
HTTP status indicating errors such as 500.
fixes CNVS-3362
Change-Id: I8af8f17590ac8e37fa2a545c9e49deadf6f3d2b6
Reviewed-on: https://gerrit.instructure.com/17176
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Brian Palmer <brianp@instructure.com>
When the Conversations/Inbox page is loaded, it will
recompute the actual unread message count for the user.
Testing Notes:
===============
When testing locally...
* Using the console, force the counts to be wrong: (First find the user by ID)
u = User.find(id)
u.update_attribute(:unread_conversations_count, 10)
* If off in positive direction, it will show the number of unread more clearly.
You can verify it on the Dashboard or other pages. If testing negative,
you need to have some conversations marked as unread and the
count will not include them.
* Visit the "Inbox" page and verify that the count is corrected. Now on the
Dashboard, it will be correct.
Change-Id: I0ccbb3489f4a296cc565fb453ae50c69637bfd60
Reviewed-on: https://gerrit.instructure.com/16770
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Myller de Araujo <myller@instructure.com>
Reviewed-by: Mark Ericksen <marke@instructure.com>
Reviewed-by: Jon Willesen <jonw@instructure.com>
fixes #CNVS-2611
also fix broken account user permission check (an account user could view
all users in a course, regardless of permissions). simplify logic in
enrollment_visibility_level_for
test plan:
1. as a student, confirm you can message the whole course
2. under account permissions, revoke "Send messages to course members"
from students
3. as a student, confirm you can only message admins in the course
Change-Id: I29d73c68b8d93c54616a515c699818025b4bb839
Reviewed-on: https://gerrit.instructure.com/16581
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
QA-Review: Cam Theriault <cam@instructure.com>
refs #CNVS-2496
TEST PLAN:
1) login as a local admin
2) navigate to the user management page for a
site admin
3) try to add a new login for them
4) it should not work!
Change-Id: I66b81162baa2508431b0d106b37ac83b9d763dd3
Reviewed-on: https://gerrit.instructure.com/16620
QA-Review: Adam Phillipps <adam@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ethan Vizitei <ethan@12spokes.com>
refs #CNVS-2634
TEST PLAN:
1) start with 2 students on the same shard
2) add 2 courses, one on the same shard as the
students, one on a different shard.
3) the target student should be given an
active enrollment in the remote-shard course
4) the distracting student should be given a
completed enrollment on the local-shard course
WITH THE SAME LOCAL ID AS THE ACTIVE ENROLLMENT
FOR THE TARGET STUDENT
5) run '#courses_with_primary_enrollment' on
the target student AR object.
6) the remote-shard course should be present
in the returned courses array.
Change-Id: Icf892839e90ea0c5e7de69802e4979db9e9d2a23
Reviewed-on: https://gerrit.instructure.com/16635
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
when adding to the user_ids, use the same type of object as the caller
Change-Id: I96ac0cd95c4b3492a398620c562af360a92e1036
Reviewed-on: https://gerrit.instructure.com/16623
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
* wrap RoleOverride#permission_for with enabled_for? that also takes a
context of where the permission is being applied, and recalculates its
enabled-ness relative to that context; use that for checking account
admin and enrollment permissions
* refactor User#can_masquerade to properly check for descendant
permissions
test plan:
* create a custom role in site admin. give it permission to
manage permissions
* in script/console, find that override and set apply_to_self=false
* add a user to that role, and login as that user
* the user should not be able to change permissions in site admin
* the user should be able to change permissions in the default
account
* add another role in site admin. give it permission to manage
permissions
* in script/console, find the override and set apply_to_self=true,
apply_to_descendants=false
* add another user to that role, and login as that user
* the user should be able to change permissions in site admin
* the user should not be able to change permissions in the default
account
* the first user should not be able to masquerade as the second user
and vice versa
* an Account Admin should be able to masquerade as either user
* create a custom role in the default account, give it permission
to manage permissions, and add a user to that role
* the first user should be able to masquerade as the new user;
the second user should not be able to masquerade as the new user
* general regression tests on permissions and masquerading
Change-Id: I20a1183b7dfec419634a92cda498f245187060ef
Reviewed-on: https://gerrit.instructure.com/15896
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Tested-by: Cody Cutrer <cody@instructure.com>
dashboards don't show these, and existing ones can be a little crazy if
they have lots of submission comments
also change cache key so these get regenerated
test plan:
1. dashboards should work
2. stream item api should work
3. specs should pass
Change-Id: I245f4464189a507f0e1a8c9dc1c4c1e9fd4b7566
Reviewed-on: https://gerrit.instructure.com/16502
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Cam Theriault <cam@instructure.com>
add support for self enrollment caps to limit the size of a particular
course. there is no UI for setting caps (yet)
test plan:
1. run specs
2. follow test plan for https://gerrit.instructure.com/15819
Change-Id: Ibf0a8f04f0c2efa820d0850cef26dfae20849246
Reviewed-on: https://gerrit.instructure.com/16021
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Joe Tanner <joe@instructure.com>
QA-Review: Cam Theriault <cam@instructure.com>
fixes #CNVS-1119, potentially supersedes
https://gerrit.instructure.com/14501 with a little work.
simpler flow that is more consistent with FFT signup. whether you click
the "join course" button (popup) or go to the join url, the workflow is
the same:
1. if you are authenticated, you just click the enroll button.
2. if you are not authenticated, you can either:
1. enter your (canvas/ldap) credentials and submit to join the course.
2. register and join the course (single form). you will then be
dropped on the course dashboard in the pre_registered state just
like a /register signup (you have to follow the link in your email
to set a password).
note that if open registration is turned off, option 2.2 is not available.
other items of interest:
* fix CSRF vulnerabilities where you can enroll authenticated users in
open courses, or un-enroll them if you know their enrollment's UUID
* move to shorter course-id-less route (w/ join code)
* reuse UserController#create
* handy openAsDialog behavior and embedded view mode
* better json support in PseudonymSessionsController#create
* extract markdown helper from mt
* show "you need to confirm your email" popup when you land on the course
page the first time (already showed on dashboard)
test plan:
1. test the authenticated/unauthenticated scenarios above, for both the
popup and join pages
2. regression test of /registration forms
Change-Id: I0d8351695356d437bdbba72cb66c23ed268b0d1a
Reviewed-on: https://gerrit.instructure.com/15902
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Joe Tanner <joe@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
- make course/account/user associations not load deleted grading standards
- make course copy not copy deleted grading standards
- never show more than 100 grading standards on a course/account page
fixes #CNVS-2230
test plan:
- in a course, create a grading standard
- delete it
- copy the course
- the destination course should not have that grading standard
Change-Id: I0063b5ca704667b2863f1d571c86df82c2a5cb97
Reviewed-on: https://gerrit.instructure.com/16108
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Amber Taniuchi <amber@instructure.com>
refs #CNVS-1292
Was unable to find any job-per-student
behavior (not to say that we won't ever discover
any), but I did find several instances of loading
full collections into memory
of student objects or objects
that would be instantiated in the same order of
magnitude as students for a course, and was able
to tweak many of those. There are undoubtably
more to find.
Change-Id: I044a1d92f90c830b4d1d07f0d4de17a718bcbe55
Reviewed-on: https://gerrit.instructure.com/16030
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
test plan:
* full regression test on dashboard stream items and activity
stream in the API
Change-Id: I7739fd7d7ea6350f6f7088b7736fd5d287e9384e
Reviewed-on: https://gerrit.instructure.com/15487
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ethan Vizitei <ethan@12spokes.com>
QA-Review: Clare Hetherington <clare@instructure.com>
expose the existing GroupsController#context_index action
to API clients.
test plan:
* create account-level and course-level groups;
* make API requests as a student and verify that:
* at the course level, all of the groups you belong
to are returned;
* course groups you do not belong to are excluded;
* at the account level, a 401 is returned.
* make API requests as a teacher and verify that:
* at the course level, all groups are returned;
* at the account level, a 401 is returned.
* make API requests as an account admin and verify that:
* at the course level, all groups are returned;
* at the account level, all groups are returned.
Change-Id: I27775def062d700c6f1c1fbae4fd83f9eb03378f
Reviewed-on: https://gerrit.instructure.com/15939
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Joel Hough <joel@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
In gradebook1 we serialize all columns in User objects, which turns
out to be a bad thing in Ruby 1.9 because it is now UTF-8 aware and
fails for some bad UTF-8 characters in the 'collkey' sortable name
column. We just remove collkey from the serializable columns and
we're good.
Test Plan:
1. Check that international characters in the sortable name field
does not break the gradebook1 page.
2. Specifically, check the original page on beta that discovered
this bug (and the only one we know for certain reproduces the
bug):
https://mtest2.beta-19.instructure.com/courses/8361/gradebook
fixes #CNVS-1972
Change-Id: I3b949faaf4abc4ae0a025ff097ec566c69fa5276
Reviewed-on: https://gerrit.instructure.com/15905
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
test plan:
* create users (with a login in an account) on two shards, then merge
them together
* enable MFA (optionally) on the account in the shard that the user
did not end up on
* log in as the user
* on the profile settings page, the link should be there to
configure MFA
Change-Id: I95468243647e3fb8f90d23b2c686c221fee8ee00
Reviewed-on: https://gerrit.instructure.com/15791
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Cody Cutrer <cody@instructure.com>
two major pieces:
* use context_type/context_id instead of context_code for
three relations so that sharding extensions will
automatically work
* deserialize stream item data as actual AR objects instead
of OpenObject (for similar reasons)
test plan:
* run the predeploy migration, but not the postdeploy one
* view your dashboard on a shard other than your home shard;
it should be identical to your home shard
* view courses that you are enrolled in with the same id but on
different shards. the activity stream should have the correct
data for the course in that shard, for both courses (i.e.
no mixing of data from the two shards)
* do actions that generate new stream items, and verify the new
items appear correctly for the above two steps
* run the postdeploy migration, wait for the job to finish, then
repeat the test plan
Change-Id: I8d5fcadb8d971acf7388a12e9151a3e927751f44
Reviewed-on: https://gerrit.instructure.com/15462
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test-plan:
- create/find a scope of users with multiple users with distinct
sortable names
- that_scope.order_by_sortable_name should still return them in
expected lexicographical order
- that_scope.order_by_sortable_name(:direction => :descending) should
return them in reverse lexicographical order
Change-Id: If3c3153e2817c8520bee8fcb9920a5fa1c8a60db
Reviewed-on: https://gerrit.instructure.com/15496
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
test plan
* existing specs should all pass
* when including teacher enrollments from course conditions should keep enrollments.type
Change-Id: Ic99fc40069b4d5ab003ed43cd1b7c9f34454a43f
Reviewed-on: https://gerrit.instructure.com/15097
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
the new dashboard design categorizes recent activity into buckets that can be
expanded/collapsed, and inidividual messages can be dismissed. the categories
are announcements, conversations, discussions and assignments. this redesign
applies to the homepage dashboard, the group home page, and the course homepage
when "recent activity dashboard" is selected as the course home page type.o
the motiviation is that the dashboard should capture and present in one place
important information happening in all the user's courses or groups, and allow
for jumping into this information to see more details:
- announcements/discussions should show on the dashboard when they are created,
or when there are root replies to recent announcements
- conversations should show on the dashboard when there is new activity
- assignments should show on the dashboard when they are created, or when
changes are made at least a couple hours after being created
the presence of a dashboard item means there is activity for that item that may
be of interest to the user. additionally, the dashboard items will show
read/unread state (excluding assignments) for items which the user has not yet
viewed.
additionally, global messages such as course inivitations, account level
announcements, and new user messages have been restyled, but will keep their
place above the recent activity widget on the dashboard.
test plan:
- visit many exising user's dashboards and make sure they are functional in the
new style.
- visit canvas as a brand new user (no enrollments), a new user enrolled in
a new course and make sure the dashboard is restyled and the messaging makes
sense.
- make an account level announcement and make sure it shows up on user's
dashboards.
- create all different types of conversations: single, group, bulk private,
from submission comment, add user to convo, etc. and make sure the
appropriate dashboard items appear and make sense
- create discussions and announcements, reply to them at the root level and at
the sub entry level (sub entries will not make new dashboard items), test
from both a read and unread user's perspective, making sure dashboard items are
correct. (note that read/unread state will not be correct for existing items
before this code is applied, but should be correct for future items moving
forward)
- dismiss dashboard items and account announcements, make sure they stay
dismissed.
- test creating assignments, waiting > 2 hours, and updating due dates or other
assignment details. make sure items appear. note that unread state will not
exist for assignment notifications.
closes#10783
refs #11038
refs #11039
Change-Id: I276a8cb1fae4c8a46425d0a368455e15a0c470c5
Reviewed-on: https://gerrit.instructure.com/14540
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test plan:
* run the specs
Change-Id: I3ecbebfa226b243c7a39d9ead0621c95583b0f84
Reviewed-on: https://gerrit.instructure.com/15119
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test plan:
* create a pseudonym with an SIS id for a user on an account in a
different shard
* GET /api/v1/users/:user_id/profile for that user against the
account's domain (easiest to just use self)
* sis_login_id should be populated
Change-Id: Idd95b949c4180abc366071a110636d348aa24806
Reviewed-on: https://gerrit.instructure.com/14875
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
also change all_pseudonyms and accounts to use the new
HasManyAssociation#with_each_shard hawtness
test plan:
* enroll the same user in courses in multiple shards
* favorites don't work yet; be sure to reset them before
continuing
* courses from all shards should show up in your menu
* courses from all shards should show up in your all courses
page
* when enrolled as a student in a course not on the user's shard,
permissions should be correct (particularly, you should be able
to participate as a student - turn in assignments)
* enroll the user in groups from multiple shards
* all groups should show up in home menu
Change-Id: I84fffa39ebf3dee093ecff145670a29296da29a1
Reviewed-on: https://gerrit.instructure.com/14722
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Fixes#10793
Test plan:
1. Go to the gradebook and verify the gradebook version you are on.
2. Go to an assignment and load up the speedgrader.
3. Click the 'Gradebook' link at the top of the page.
4. You should be on the same version of the gradebook as you were
originally. Repeat steps 1-3 after switching to the other gradebook.
Previously, you were always taken to gradebook 1.
Other notes:
* Adds a 'gradebook_url_for' helper that accepts a user, context, and
assignment and constructs a URL based on the user's preference
Change-Id: I596202d448c61046efae1e13ab8c9e87c3f7768b
Reviewed-on: https://gerrit.instructure.com/14666
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
...in the CountReport to only users with a pseudonym that's been
accessed in the last 30 days. fixes#11381
Change-Id: Ic4c10b1bd49bc9f10e5d4ef20a7ea2bd78ab27b9
Reviewed-on: https://gerrit.instructure.com/14780
Reviewed-by: Rob Orton <rob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
we're doing work and consuming storage keeping track of reminder
information that nobody is consuming.
should we decide to implement assignment reminders in the future,
reverting this commit would be an excellent start; then a
delayed_job that periodically called remind! on each result of
AssignmentReminder.needs_sending would get us most of the
way there.
Change-Id: I2b110cab79d53229b30c9fef64aac646b719a700
Reviewed-on: https://gerrit.instructure.com/14569
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
* don't use set_shard_override, just set shard= directly
* when creating follows, run the transaction, the search, and
the create all on the same shard
* when searching for upvotes, root on the user, not the
collection item
Change-Id: I5ae3f29e5f48f92c02d3a0c0e04765956d8eb892
Reviewed-on: https://gerrit.instructure.com/14648
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
instead of relying on clone creating the object on the
currently active shard
test plan:
* same as previous cross-shard user merge test plan
Change-Id: I710bce60456ec5bcb11eb8d5fe56aa074e22be89
Reviewed-on: https://gerrit.instructure.com/14685
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Adds a new back-end store for page_views, using a Cassandra cluster. All
the current page view queries are supported, many using denormalized
views on the data.
test plan:
first, canvas instances that are currently using AR page views
should function as before.
by Setting.set('enable_page_views', 'cassandra') and restarting, you will
switch to cassandra page views. a script to migrate the AR page views to
Cassandra is coming. all page view functionality should work as before.
note that the format of the pagination headers in the
/api/v1/users/X/page_views endpoint has changed.
Change-Id: I2d1feb4d83b06a0c852e49508e85e8dce87507b4
Reviewed-on: https://gerrit.instructure.com/14258
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Jon Jensen