[Building Sakai] proposal to deal with Gradebook / Lessons interaction

[Charles Hedrick]

That sounds good.

I'll have to think about returning control to the tool if the Lessons page is deleted. But that's a problem we have now. It's not an issue for gradebook, since I'll give the same answer the original tool would have if I hadn't replaced the groups. Rather, it means students' ability to take the quiz or whatever will still be controlled by Lessons when it shouldn't be. But that's am existing issue, and it's never been reported in practice.

On Jul 2, 2013, at 8:42 AM, Noah Botimer <nbotimer at unicon.net> wrote:

> Thanks for thinking this through. It all sounds reasonable. I will look at this more tonight and see if there is a clear winner as far as implementation. I'll share what I come up with in my GitHub repository so we can review/refine.
> 
> It's worth mentioning again that we originally iterated through known assignments and checked with all providers, but that fell flat as far as performance. We added getExternalAssignmentsForCurrentUser to do things in batches, so the single-item calls are really not used for list building -- they are almost warts now.
> 
> Each provider also presents its own difficulties because they use the service APIs, which are often scoped to the UI actions -- full list or subset operations are sometimes just not exposed and permissions are enforced in different ways. I'll have to work through some more details to see if there are roadblocks.
> 
> I think recording an "owner" tool/provider is long overdue. In the Lessons case, I think you could assume gradebook authority for the items in other tools and release additional items as you describe. This would take the shape of the gradebook making a list of items per provider and calling each with those it thinks the tool is responsible for. Note that this eliminates the possibility of a chain of responsibility unless coordinated directly between providers -- but I don't think that's a problem. We'd just have to remember the original value so it could be reset if the item is taken out from under the Lessons umbrella.
> 
> We can talk about how to avoid duplicating some of the nasty code if it looks like you would need to make some of the same calculations as the tools.
> 
> I'm glad to have others riding along through this code. It'd be dangerous to be here alone.
> 
> Thanks,
> -Noah
> 
> On 07/02/2013 07:23 AM, Hedrick Charles wrote:
>> It's a difficult issue. At the moment, Lessons always adds access. That is, any assignment that would be visible through the tool should be visible to Gradebook, but there are cases where someone should be able to see an item and it isn't currently visible through the item's normal tool.
>> 
>> Of the 3 methods defined in the interface, it appears to me that two of them effectively combine access. So if Lessons simply responds for everything it knows about we might get the right result. With isAssignmentVisible, however, the last provider to respond wins. That is, if you replace
>> 
>> visible = providerValue
>> 
>> by
>> 
>> if (providerValue)
>>     visible = true
>> 
>> then I think you'd get the right result. The main issue is that it's slightly inefficient, because both Samigo and Lessons would go through the computation. That may be acceptable.
>> 
>> Will it always be the case that a tool like Lessons only adds access? I think so. Whatever weird stuff we may do with groups, the purpose is to control more carefully when students can see things. But we'd never allow the tool to show the item if in the end it's not going to count, even if we don't permit an item to be shown yet. But perhaps some other tool would have a reason to let Samigo show a test, but ultimately decide that it shouldn't count?
>> 
>> My gut feeling is that it is better to add a field saying which tool is responsible for the item. Then you'd add a parameter to 2 of the methods giving a list of items for which you want a response, rather than (as now) asking the provider to find all tools in the site that it knows about. That could potentially be useful in paging. Gradebook could ask for judgements for only the items that might be shown on the current page.
>> 
>> Aside from isAssignmentVisible, my methods always start by a query to find all items in the site. So passing a list of items would save a database query. I belive the grade book code already has the list of assignments, so passing a list of assignments wouldn't require it to to any more work.
>> 
>> The only concern I can see with this is that if more than one tool like Lessons is interesting in an item it could be difficult for them to coordinate who is responsible. Let's hope that doesn't happen, since if two different tools are replacing the group list with fake groups, we've got a problem anyway.
>> 
>> 
>> On Jul 1, 2013, at 7:56:21 PM, Noah Botimer <botimer at umich.edu> wrote:
>> 
>>> Charles,
>>> 
>>> I designed the original interface and it definitely has some warts. It is a set of compromises.
>>> 
>>> I am looking, today and tomorrow, at a core issue -- that external items going into the gradebook give a display string ("Assignments", "Tests & Quizzes", etc.) to be persisted and no real identifier of the originating/authoritative tool ("sakai.asn.grades" "sakai.samigo").
>>> 
>>> The sort of chain of responsibility in isAssignmentDefined/getExternalAssignmentsForCurrentUser is there to work around this problem, but it causes another (SAK-23733, which you ran into with LSNBLDR-429). It's also not practical to ask about each item (performance in SAK-22978). As it stands, if no provider speaks for a given external assignment, it is assumed that the item should not be visible to the student.
>>> 
>>> The two basic approaches I've considered (that don't constitute a lot of iteration) are 1) to record the tool ID with the gradebook item and make sure that the providers register under that ID so they can be called back, or 2) set up a method to ask a provider for all of its external items in a site so the complete and visible lists can be compared. In both, any item that has no advice provided at all should be visible to match legacy behavior; the allow/deny advice should apply for all those that are spoken for (in any provider's complete activity list).
>>> 
>>> Your scenario, though, presents a more complex requirement. If I understand correctly, you effectively want Lessons to stand as a proxy for other tools in certain cases. So we'd either have to make those providers aware of the Lessons mechanism or solve it architecturally like you suggest (or maybe it's solvable now; see last sentence).
>>> 
>>> Just so everyone is clear on how things work now (mildly bugged as in SAK-23733), each provider is asked for the list of external gradebook items that should be visible to a given user in a given site (on whatever terms the tool decides: groups, timed release, etc). Anything that is marked external in the gradebook but does not come back as visible from some provider is removed.
>>> 
>>> To be clear, there is currently no "owner" of external items. Any provider can answer affirmatively that an item should be visible/graded.
>>> 
>>> SAK-23733 is addressing the issue of items from tools that do not have a provider implemented being filtered from the students' view.
>>> 
>>> This new issue is about Lessons being able to tell the gradebook that certain items should be considered for grading though they are not (yet) available within the tool.
>>> 
>>> Charles: Is this accurate regarding your need? Does it give you an indication that some path is the right one? We may be able to just have Lessons include the items in question in its visible list to solve one of these two problems.
>>> 
>>> Thanks,
>>> -Noah
>>> 
>>> On Jul 1, 2013, at 2:57 PM, Charles Hedrick wrote:
>>> 
>>>> Ugh. I was thinking of isExternalAssignmentVisible. Other approaches would be needed for the other methods. Still, I do believe it would be feasible to do it by this approach rather than actually modifying the Assignment and Samigo ExternalAssignmentProvider's. I'd be willing to do the code if people agreed on this approach.
>>>> 
>>>> 
>>>> On Jul 1, 2013, at 12:14 PM, Charles Hedrick <hedrick at rutgers.edu> wrote:
>>>> 
>>>>> I propose adding to ExternalAssignmentProvider one more method:
>>>>> 
>>>>> registerInterceptor (class)
>>>>> 
>>>>> the class has the same profile as the existing ones, but with Boolean rather than boolean.  The methods are prepared to handle assessment IDs from any tool, not just their own. They will return a value, or null if they're not interested.
>>>>> 
>>>>> If more than one tool register interceptors they should all be called. The first one to return a value is used. If they return null, go on to the next one.
>>>>> 
>>>>> The Lesons implementation will guarantee to use sufficient caching that they do not add significant overhead for items they're not interested in.
>>>>> 
>>>>> My understanding is that some tool other than Lessons does something similar with groups. Hence a general design rather than Lesson-specific hacks.
>>>>> 
>>>> 
>