[Contrib: Evaluation System] provider not being called

Aaron Zeckoski azeckoski at unicon.net
Thu Sep 30 07:57:21 PDT 2010


> Where I do think it's appropriate is that when the evaluation closes,
> the set of users at whom it was targetted should be static (i.e.
> changing membership of the site or whatever shouldn't affect the
> completion rate, etc.).

In the previous code, a change in Sakai sites (like removing them or
removing user memberships) or a change in the data from the provider
would make evals results data inaccessible (or worse, incorrect).

-AZ


On Thu, Sep 30, 2010 at 9:35 AM, Stephen Marquard
<stephen.marquard at uct.ac.za> wrote:
> I have a vague memory of round about when this changed. It may have been
> related to changes around user roles in an evaluation (i.e. student, TA,
> instructor, etc.) but it wasn't a functional requirement of any of UCT's
> changes so I think it was more of a back-end refactor as Aaron says to
> address performance issues.
>
> We've found it a minor usability issue that creates occasional support
> calls (mostly because the behaviour is unexpected compared to other
> tools), so we'd support introducing some type of periodic
> synchronization update (an event listener on realm.upd events could be
> one mechanism for our use case).
>
> Where I do think it's appropriate is that when the evaluation closes,
> the set of users at whom it was targetted should be static (i.e.
> changing membership of the site or whatever shouldn't affect the
> completion rate, etc.).
>
> Also to clarify, AFAIK we don't use a provider as such for evals (i.e.
> it uses the membership of our Sakai sites), so the issue is slightly
> higher level than the way an evals provider is invoked (or maybe that's
> just semantics, not being too familiar with the backend internals).
>
> Regards
> Stephen
>
>>>> Aaron Zeckoski <azeckoski at unicon.net> 9/29/2010 4:53 PM >>>
> In short, the provider is consulted when the evaluation is created
> (or, more accurately, when the assignments are adjusted). First, the
> provider will determine which groups are viable to be selected. Then
> the provider answers the questions about who is allowed to take the
> eval and who is being evaluated in those groups. Both of these types
> of data are mapped into the tables for the evaluation. The groups data
> was always mapped into the tables since version 0.1 (maybe 5 years
> ago). The memberships change is fairly recent by comparison (as in, it
> happened about 2 years ago).
>
> Providers don't do anything with tables. They only are able to answer
> questions and do not really know anything about the internals of the
> system (nor should they). It is not timed. It is action driven. There
> is no syncing unless the assignments are changed.
>
> My memory on the precise reasoning behind these changes is somewhat
> fuzzy at this point since it has been quite awhile since the changes
> were made but I do recall it was related to performance and relevance
> of the data. I think UCT was at least partially involved so Marquard
> might have some comments.
>
> -AZ
>
>
>
>
>
> ###
> UNIVERSITY OF CAPE TOWN
>
> This e-mail is subject to the UCT ICT policies and e-mail disclaimer
> published on our website at
> http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from
> +27 21 650 4500. This e-mail is intended only for the person(s) to whom
> it is addressed. If the e-mail has reached you in error, please notify
> the author. If you are not the intended recipient of the e-mail you may
> not use, disclose, copy, redirect or print the content. If this e-mail
> is not related to the business of UCT it is sent by the sender in the
> sender's individual capacity.
>
> ###
>
>



-- 
Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile


More information about the evaluation mailing list