[Building Sakai] issue with grade book, lessons, asssignment/samigo

[Charles Hedrick]

Unfortunately it's worse than that. When we take over control of an object, we replace the groups with our own. Normally tools allow anyone in any group to use it. So adding our own control group wouldn't do what we need. We have to replace the groups. We then stash the original groups away in our own table. In effect the accessibility test is that the user is both in our own group and in one of the groups originally associated with the object.

So the actual code is going to be that we check to see whether an object is controlled by one of our groups, and if so we return the actual groups from our own data. You'd think this would be a trivial change but looking at Samigo's AssessmentGradeInfoProvider.java, it looks non-trivial. I'm willing to write it, but this is going to end up being a for 2.9.3.

I agree about https://jira.sakaiproject.org/browse/LSNBLDR-141?focusedCommentId=178549&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-178549. I promised to do something about this, but we need to get past the 2.9.3 stuff first. A real fix to LSNBLDR-141 is unlikely to have much impact on the way we handle the gradebook issue. 


On Jul 1, 2013, at 12:28 AM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:

> Which providers are you referring to? Signup does a similar thing with groups. site manage looks for a specially named property and ignores it if not set ( though there is a display bug). I think other tools respect the prop too but I am not 100% on that, away from source. 
> 
> Cheers
> Steve 
> 
> Sent from my iPhone
> 
> On 01/07/2013, at 7:59, Hedrick Charles <hedrick at rutgers.edu> wrote:
> 
>> Makes sense. But we still need to add code to the existing providers. Is that something that sounds feasible for 2.9.3?
>> 
>> On Jun 30, 2013, at 4:52:59 PM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
>> 
>>> Why don't you use a group property to distinguish groups from each other?
>>> 
>>> Cheers
>>> Steve
>>> 
>>> Sent from my iPhone
>>> 
>>> On 01/07/2013, at 5:28, Hedrick Charles <hedrick at rutgers.edu> wrote:
>>> 
>>>> I've just finished implementing SAK-19668 for Lessons. My implement has no architectural issues. However in the course of doing it, i noticed a design problem.
>>>> 
>>>> Lessons uses groups to control release of items if the instructor declares pre requites. It is common say that you can't take the quiz on a unit until you've contributed to a forum and submitted an assignment. In this case the quiz is modified so it is released only to a group whose membership is controlled by Lessons. As people become eligible, they are added to the group. 
>>>> 
>>>> This creates a problem with the new grade book. It is very likely that you want to include the quiz in everyone's grade computation, even if they haven't gotten to it. You surely want the final grade to reflect the fact that someone didn't finish the lesson. But currently if a quiz is controlled by Lessons, it will show in Samigo as not released to the student until lthe student meets the perquisites.
>>>> 
>>>> The groups are currently identifiable by a specific prefix in their group name. The current test is
>>>> g.getTitle().startsWith("Access: ")
>>>> This is less than ideal: it's not internationalized, and clutters the Group tool. But that's all I could do initially. 
>>>> 
>>>> For 2.9.3, I see two possibilities:
>>>> * fix the existing providers so they ignore these access groups
>>>> * let sites disable the whole feature in Lessons. I doubt most site will like that, however.
>>>> Fixing the providers should be trivial, but either someone has to go through them all, or it will require cooperation by several maintainers.
>>>> 
>>>> For 2.10, it would be nice if we had a way to designate groups as this special kind of group.
>>>> 
>>>> _______________________________________________
>>>> 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"
>>