by Jake Dallimore.
I think that makes sense. Setting a grouping on the activity like this would appear to suggest similar Grouping behavior to the assignment module in that a student will be unable to participate in the activity unless they are present in one of the groups within the grouping. What I was more getting at,
I'll just type it out so I'm sure we're talking about roughly the same kind of thing.
So, in your example, while certain students are clearly in groups (and a grouping perhaps) denoting the need for extra quiz time, we can prevent these groups being sent to the tool by setting a grouping on the external tool - a grouping that doesn't include these special sensitive groups. Is that right?
So, in your example, while certain students are clearly in groups (and a grouping perhaps) denoting the need for extra quiz time, we can prevent these groups being sent to the tool by setting a grouping on the external tool - a grouping that doesn't include these special sensitive groups. Is that right?
We'd still have a means to allow all users to participate in the tool too. It's possible (likely?) that the students in these 'extra time' groups are in other course groups as part of a wider class grouping. If we were to set the external tool settings to use this wider course grouping, then only the 'non-sensitive' (for lack of a better term) groups will be exchanged with the tool (either as part of the course groups service work, as as part of your custom work for LTI 1.1). All students will still have access to the activity. I think I've got that right but please correct me if I've missed something there.
Then, providing the above is correct, we also need to make sure that the external tool knows what to do in cases where the student is NOT a member of any of the groups within the set grouping. In these cases, I think the activity should stop the user from being able to launch, similar to the way that the assignment blocks submissions for users outside the set grouping.
The next logical to then consider would be the membership service. We'll want to be sure that requests for membership return only those members in the set grouping. This would be similar to the way we don't return members who don't have access to the activity, I guess.
None of this causes me great concern for 1.1 because if a grouping isn't set, we just continue to exhibit the same behavior as we currently do.
Then, providing the above is correct, we also need to make sure that the external tool knows what to do in cases where the student is NOT a member of any of the groups within the set grouping. In these cases, I think the activity should stop the user from being able to launch, similar to the way that the assignment blocks submissions for users outside the set grouping.
The next logical to then consider would be the membership service. We'll want to be sure that requests for membership return only those members in the set grouping. This would be similar to the way we don't return members who don't have access to the activity, I guess.
None of this causes me great concern for 1.1 because if a grouping isn't set, we just continue to exhibit the same behavior as we currently do.