refs CNVS-13987
what was called CanvasUuid was *not* generating UUIDs. it was generating
slugs. by default, its generate method only creates 4 character slugs.
these should obviously not be used as UUIDs. the misnomer already caused
a bug in EventStream where it used these slugs as UUIDs, causing
collisions. to fix:
(1) rename canvas_uuid gem to canvas_slug, and rename it's primary
class CanvasUuid to CanvasSlug
(2) create new canvas_uuid gem, with class CanvasUUID, extracted from
lib/uuid_singleton for actual UUID generation
(3) fix event stream use CanvasUUID, rather than following the rename
of CanvasUuid to CanvasSlug
test-plan:
- have cassandra set up for audit logs
- create an audit log entry (e.g. change a grade)
- look at the generated audit log entry's id field; it should be a UUID
value, not a 4 character slug
Change-Id: I19758fff4433cd6cb2e21219217dced19ee05c5a
Reviewed-on: https://gerrit.instructure.com/37506
Reviewed-by: Rob Orton <rob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: August Thornton <august@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
closes: CNVS-11834
This creates a way for an instructor to
assign a random student as the group leader.
It only applies when an instructor is having groups
created automatically at the time of defining
a group category.
This also take an opportunity to refactor out
some bloated code from the group_categories_controller
and move it into some separate objects
that can be more easily understood and rapidly
unit tested through all the necessary permutations
(allowing higher level integration tests to just
cover a case or two)
It ALSO removes group leadership knowledge into
it's own object so that the callbacks in other
objects are simple and the logic regarding
how to do group leadership management is in
one place.
TEST PLAN:
AUTO_DISTRIBUTION:
1) login as an instructor
2) go to the "people" tab and try to create a group
set.
3) click on the "Create [0] groups for me" radio
button; verify you now have controls for assigning
a group leader automatically and that the strategy
radio buttons are greyed out.
4) check the "Assign a group leader automatically"
checkbox; verify the 2 nested radio buttons for
"random" and "first" strategies become enabled
5) select a strategy and fill out the rest of the
form, then submit (make sure your background job
is running)
6) verify after groups are created that each group
has a leader, and that the leader is in fact a member
of the group.
SelfSignup:
1) login as an instructor
2) go to the "people" tab and try to create a group
set.
3) enable self-signup.
4) check the "Assign a group leader automatically"
checkbox; verify the 2 nested radio buttons for
"random" and "first" strategies become enabled
5) select a strategy and fill out the rest of the
form, then submit.
6) Login as a student for the same course and join
the group.
7) verify that the student has been made the group
leader.
Change-Id: I2cdd9f5ed2fd577469beec4ab7369c69ecf7eaa6
Reviewed-on: https://gerrit.instructure.com/35130
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Braden Anderson <banderson@instructure.com>
QA-Review: Trevor deHaan <tdehaan@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
fixes CNVS-11833
test plan
- regression test teacher view of groups page
a group can only have one group leader, and that user must be in
the group. anything that can be done to remove a user from a
group should revoke their leadership if they have it. a user's
leadership should not be revoked unless the teacher revokes it,
a different leader is chosen, or that user leaves the group. a
leader's user should have a user icon on it and their name should
appear next to the group's name
a few test cases:
- set group leader using gear menu on user in group
- revoke the leadership of the user using the gear menu
- ensure that the group is now leaderless
- set a group leader
- set a different user as leader
- ensure that a screenreader identifies the group leader link as "Group
Leader"
- ensure that the first user is no longer the leader
- set a group leader
- remove that user from the group by dragging and dropping
- ensure that the user is no longer the group leader
- set a group leader
- move the user to another group using the option on the gear
menu
- ensure that the user is not the leader of their original or new
group
- in a large-roster course, add users to a group user the plus
button next to the gear menu
- set a group leader using the gear menu next to a user
- fill a group up to it's maximum limit of students
- ensure that the "full" label shows up for that group
- ensure that when you narrow the browser size, you can
still tell that the group is full
Change-Id: I8bb1b62e0f36a37a24e050878c945f822fe9f66c
Reviewed-on: https://gerrit.instructure.com/34360
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Trevor deHaan <tdehaan@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
instead of passing an :exportable option to
ActiveRecord::Associations, simply define a constant
on the class containing exportable associations and
attributes. This is due to :exportable breaking
ActiveRecord, and we can't simply monkey-patch in
config/initializers because models are included in
migrations before the initializers are run
Change-Id: I11f1a6b4570c397d8e01010c517bc6efdac7afca
Reviewed-on: https://gerrit.instructure.com/33235
Reviewed-by: Braden Anderson <banderson@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Anthus Williams <awilliams@instructure.com>
QA-Review: Anthus Williams <awilliams@instructure.com>
Change-Id: Ic226e61e900532cc3acf08444b316b6e2bb6b368
Reviewed-on: https://gerrit.instructure.com/30049
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
This was a beta api that didn't work out.
Test plan:
canvas should still work (sorry, this touches lots of stuff)
Change-Id: I31680b83f72f6d739ce74735ba40d7a760debb33
Reviewed-on: https://gerrit.instructure.com/29506
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
Product-Review: Cameron Matheson <cameron@instructure.com>
fixes CNVS-10561
when a group membership has been created through sis, it
should not send a notification to the new group member.
test plan:
* as a student in a course, set your notification
preferences to ASAP;
* using an sis import, create a new group;
* using an sis import, create a membership in the group
for the student in step 1;
* verify that the student has not received a notification
about their group membership.
Change-Id: I4509f1614faa2e094323a272ff57ec24610d988d
Reviewed-on: https://gerrit.instructure.com/28724
Reviewed-by: Joel Hough <joel@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Steven Shepherd <sshepherd@instructure.com>
Product-Review: Zach Pendleton <zachp@instructure.com>
deleting a user could cause thousands of update-cached-due-dates
jobs to be enqueued (one per assignment per enrollment; in the
referenced ticket, the test student had 13 enrollments and there
were 88 assignments, yielding 1,144 jobs, causing the request
to time out).
fix this by
(1) using a batch job to update all assignments in the course,
instead of a job per assignment
(2) when deleting a user with multiple enrollments in a course,
only run the update cached due date job once per course
test plan:
0. run in "production" configuration (i.e., in QA portal)
1. have a course with 10 sections and 100 assignments.
I suggest creating these in the console, e.g.
course = course.create! name: "CNVS-8068"
10.times { |x| course.course_sections.create! name: "section #{x}" }
100.times { |x| course.assignments.create! name: "assignment #{x}" }
2. enter student view mode in this course
3. reset the student view student
4. verify 1000 jobs were not created (and the request doesn't time out)
fixes CNVS-8068
Change-Id: If00dd3197b70df42b0f9ec18303b02594861f69f
Reviewed-on: https://gerrit.instructure.com/25160
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Matt Fairbourn <mfairbourn@instructure.com>
Product-Review: Bracken Mosbacker <bracken@instructure.com>
include conditions on the context, so it can use that index
test plan:
* have at least one student in a course
* create a new group category
* it should work
Change-Id: I793d42a8838872eee407a3ba19362c14940f2d47
Reviewed-on: https://gerrit.instructure.com/23876
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
fixes CNVS-6887
use a smarter query, and skip it altogether for account groups
test plan:
* regression test adding/removing users to groups in a course with
overrides and stuff.
* an sis import of account level groups should still work
Change-Id: Ie9943af04ce6aab31f9f0d76f51c7474c1299616
Reviewed-on: https://gerrit.instructure.com/22317
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
refs CNVS-5805
with efficient calculation of all due dates for any submissions for a
given assignment when related records (the assignment, its overrides,
related enrollments, and related group memberships) changes.
compares this cached due date to the submitted_at or current time when
determining lateness.
populates the column for existing submissions in a post-deploy
data-fixup migration.
test-plan:
- run lib/data_fixup/initialize_submission_cached_due_date.rb
- all submissions' cached_due_dates should be updated over several
jobs
- enroll a student in a course and create submissions in that course
- create a second enrollment in a second section; the
cached_due_dates for the user's submissions should recalculate
- destroy the second enrollment; the cached_due_dates for the user's
submissions should recalculate
- create a group assignment
- add the student to a group in the assignment's category; the
cached_due_dates for the user's submissions should recalculate
- remove the student from the group; the cached_due_dates for the
user's submissions should recalculate
- enroll more students in the course
- change an assignment's due date; the cached_due_dates for the
assignment's submissions should recalculate
- create an override for the assignment; the cached_due_dates for
the assignment's submissions should recalculate
- change the due date on the override; the cached_due_dates for the
assignment's submissions should recalculate
- delete the override; the cached_due_dates for the assignment's
submissions should recalculate
- during any of the above recalculations:
- the most lenient applicable override should apply
- if the most lenient applicable override is more stringent than the
assignment due_at, it should still apply
- the assignment due_at should apply if there are no applicable
overrides
Change-Id: Ibacab27429a76755114dabb1e735d4b3d9bbd2fc
Reviewed-on: https://gerrit.instructure.com/21123
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
Tested-by: Jacob Fugal <jacob@instructure.com>
test plan:
- go to the groups page of a course or account
/courses/*/groups or /accounts/*/groups
- edit a group category by clicking on the pencil icon or
click 'make a new set of groups'
- check the 'Allow self sign-up' checkbox
- a textbox should appear to limit group members
- enter a number (2 or 3) for the group limit and save
- add at least on group
- masquerade as students in the course and join a group until it's full
- once the group is full students should not be able to join the group
- also, when editing a group category you should be able to remove the group limit
Change-Id: I0d035320a171b03a7cd2e4d81ecb0648c5aacad0
Reviewed-on: https://gerrit.instructure.com/20309
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Cam Theriault <cam@instructure.com>
Product-Review: Joe Tanner <joe@instructure.com>
if there were two active memberships for the same user in different groups
within the same group category, they would endlessly try to destroy each other.
fixes CNVS-4835
test plan:
- set up the situation above (i'm not sure how to do this in the UI yet, but
from the console you could do something like this:
https://gist.github.com/simonista/82201b9075748ae591c6)
- now try to create a third group in the UI and drag the user into it
- It should work, and the user should be removed from the other two groups.
Change-Id: I4787845082092ab928de5098e77f02be2aa981d6
Reviewed-on: https://gerrit.instructure.com/18920
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Amber Taniuchi <amber@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
When a GroupMembership is updated, don't check to make sure the user's
group is within the section, as this could impact SIS imports. We
only care about validating homogeneity when creating a new
GroupMembership.
Test Plan:
- create a batch import in which a user is enrolled in a class,
and is also in a group within that enrollment
- add something else to the batch (to test that the rest of the
batch is imported even when the error, below, occurs)
- import the batch
- mark the enrollment as deleted
- re-import the batch
- rather than failing to import the batch, there should be an
error message indicating the group user had a validation error
fixes CNVS-4225
Change-Id: I2a20756d0464d833ce66e94a4d6c847bfb894f14
Reviewed-on: https://gerrit.instructure.com/18455
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
fixes#11637
test plan
* have a course group with a student
* delete the student enrollment
* group membership should be soft deleted
Change-Id: Ieba3f7dabee693a4572f8c382da12dcbc4182fbf
Reviewed-on: https://gerrit.instructure.com/15297
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
fixes#10690
previously, notifications only considered user locale settings
when translating; they now consider the context as well.
test plan:
* create a course with a spanish or russian locale;
* enroll an english user in the course;
* verify that the enrollment email is sent in the course
locale and not the user locale.
Change-Id: Ib942f35dff770ec02aa4e39880a5234e318f26a9
Reviewed-on: https://gerrit.instructure.com/14103
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
fixes#10268
group invite wasn't searching in the correct account when trying to match user
emails passed in to users. group membership creation was broken for
non-community account level groups to to a missing permission.
test plan:
- create an account level group
- invite someone who belongs to that account to the group with the api
- they should be added (it should not create a temporary user)
- now add someone else directly with the api be creating a membership for them
- it should work
Change-Id: I7bb7a22b83e13ed6e9575aa059e3e3463e0541f9
Reviewed-on: https://gerrit.instructure.com/13337
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
also a fix for UserFollow#check_auto_follow_collections, which was kind
of only working by accident across shards.
test plan: have a user join a group in another shard, and see that they
auto-follow collections in the group. have them leave the group, and see
that they auto-unfollow private collections in the group.
Change-Id: Ic1efd9e527d14d4a21c0db828ba228dd0b3753e8
Reviewed-on: https://gerrit.instructure.com/11719
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
when a user joins a group, they should automatically be following the group,
which will cascade to follow collections and allow them to show up in the
stream. when a user leaves a group, the should automatically stop following
the group.
test plan:
- join a group that has collections with items
- make sure you are following the group collections
- make sure those items end up in your stream
Change-Id: If615a607505452a7688563cc1ebb2d4be999241f
Reviewed-on: https://gerrit.instructure.com/11489
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
allow users to join, or request to join groups and leave groups they are part
of, if the group allows those actions. allow moderators to invite others
to the group by email address. allows moderators to add or remove moderator
privleges of other group members.
test plan:
- no ui yet, so try these api actions manually and make sure they do the right
thing.
Change-Id: I2765f07acb131e503add67b0daa37f18fdbde6c2
Reviewed-on: https://gerrit.instructure.com/11229
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Uses the same functionality as following users and collections.
test plan: use the new api endpoints to follow and unfollow groups.
Verify that you can't follow private groups unless you are a member.
Change-Id: I329a6ff31031c0b501cfc724f193bf6c89db1af7
Reviewed-on: https://gerrit.instructure.com/11323
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
this adds show/create/edit/delete api actions for groups. currently create
only allows creating community groups. the changes to these controller
functions should be backwards compatible with course and student groups.
anyone should be able to create a community (for now), but only moderators or
account admins are allowed to edit/delete them.
test plan:
- test the four api actions from the command line
- make sure managing course and student groups still works (there should be no
visible changes here)
Change-Id: I9cac73ab434b0ba464ecfe399ab42174eff9b48a
Reviewed-on: https://gerrit.instructure.com/11148
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
this commit just lays down a bit of ground work for communities. it defines
communities as a protected group category type for accounts which allows
membership in multiple groups. it also generalizes several places where student
organized groups was a special case. it also removes the restriction that
group.is_public always be false. this property will be used for different
visibility levels within communities. finally, it lays some groundwork for
handling group requests/invitations/following.
test plan:
- there should be no functional changes from this commit
- you should be able to run GroupCategory.communities_for(account) at the
console for an account, and get a category shell for communities for that
account.
Change-Id: Icff3f0e7fbd4ec3c0a72cdbaa310cbd0e75d0e3e
Reviewed-on: https://gerrit.instructure.com/10780
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
test plan:
* create and publish a course
* invite and accept a student
* change the course dates to the future, and restrict access to
them
* create a web conference
* the student should not get a notification
Change-Id: I06b0226c01fd38f99afed0ce767e9e7207864fbe
Reviewed-on: https://gerrit.instructure.com/10288
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
student group memberships support requested and invited states, but there isn't
currently frontend support for accepting these memberships. students in these
states had an inconsistent group experience. this fix retroactively accepts
these memberships, and causes new memberships in these states to be
auto-accepted. it also tries to be more consistent about showing group
membership counts/members based on accepted memberships.
test plan:
- create a student organized group, inviting some people
- make sure the counts are right.
- refresh the page and make sure the counts match the group members
- make sure the people you are invited are "accepted" in the db
Change-Id: Id0e3f183a99bd4962497388ead6884243938e6fc
Reviewed-on: https://gerrit.instructure.com/8736
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
account group memberships don't need a corresponding active enrollment
to be displayed in the Courses & Groups menu. fixes#6008
Change-Id: I136f1b33ed650cc7a88eaefb7f72adc0e65486e0
Reviewed-on: https://gerrit.instructure.com/6344
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
group categories can be flagged as self sign-up, and optionally
restricted to be section-homogenous. like normal groups and unlike
student-organized groups, a student may be in at most one self sign-up
group. but like student-organized groups and unlike normal groups,
students can assign themselves to the group of their choice. if the
section restriction is enabled, students can only be assigned (whether
by themselves or their teacher) to a group which is either empty, or
whose existing members are in the same section as the student.
also added an edit UI to group categories allowing renaming and
management of the self sign-up options. polished the existing UI for
creating categories.
fixes#4624
Change-Id: Ib623f4c6afd20e9700984f8294cd42950107252c
Reviewed-on: https://gerrit.instructure.com/6052
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Whitmer <brian@instructure.com>
just like we hide inactive enrollments from the "Courses" menu, also
hide groups from courses that don't have an active enrollments in the
groups portion of the "Courses & Groups" variation of the menu
fixes#5797
Change-Id: I91a9fd742b04faab5d97793b6baa17409a4f043a
Reviewed-on: https://gerrit.instructure.com/5901
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
wrap Assignment#group_category and Group#category accessors as
Assignment#group_category_name and Group#group_category_name accessors,
respectively, in order to make naming consistent and free up the field
"group_category" for a new association.
Change-Id: Ieb926088d96ebb8b46f70768a77b82fa1dcc8817
Reviewed-on: https://gerrit.instructure.com/5761
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
update_all's update hash doesn't have any magic performed on bare Time
objects; it assumes any Time object it's given is already in UTC. using
a TimeWithZone object (regardless of timezone), which Fixnum#ago and
friends happen to return, is still fine.
Change-Id: I297b2a3211b896b5225ebcfaaee3c1eb56e55fb6
Reviewed-on: https://gerrit.instructure.com/5351
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Jacob Fugal