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

[Noah Botimer]

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.
>> 
> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"