[Contrib: Evaluation System] provider not being called

Tue Sep 28 07:37:52 PDT 2010

Thanks Aaron,

Ok, I see EVAL_ASSIGN_USER as a new table -- I assume this is where the
eval users get stored.  What I don't understand is what happens when we want
to assign an evaluation to a user who has not yet signed on to Sakai?  We
have many
users who only use Sakai for evaluations.  Where do we find the internal
Sakai uid
for such a user?

   -- Aaron Watters

PS: Chuck, you are not getting copied on some of these messages, you may
   want to consult the list archive.

On Tue, Sep 28, 2010 at 10:02 AM, Aaron Zeckoski <azeckoski at unicon.net>wrote:

> Jim,
> That is correct. The group provider is only consulted when setting up
> the evals or updating them. Otherwise, the internal DB groups records
> are used. This was done to remove the bottlenecks and performance
> issues related to providers which were not written as efficiently. It
> also simplified a lot of the logic by removing complex merges of data
> from various sources.
>
> For the rutgers situation, it may be beneficial to examine the groups
> tables and see if data is missing. If the groups tables have the data
> but the users still are unable to access things then there might be
> something wrong.
>
> -AZ
>
>
> On Tue, Sep 28, 2010 at 8:40 AM, Jim Eng <jimeng at umich.edu> wrote:
> > I am following this discussion closely because we are hoping to move to a
> > newer version of evalsys.  It seems to me that Aaron Z told us a year or
> so
> > ago that the way the group provider works had changed at some point.
> > If I recall correctly, in early versions of evalsys, the provider was
> > consulted frequently while handling user requests.  In trunk (or 1.3.x),
> I
> > think he said that the group information is stored internally and the
> group
> > provider is consulted occasionally to update it.  That was done to
> > streamline queries that matched users with evals by group membership,
> IIRC.
> >
> > Is this a correct description?  If so, your question might be why the
> group
> > info is not being persisted adequately within sakai, rather than why the
> > group provider is not being consulted in handling particular requests.
> > Jim
> >
> >
> > On Sep 28, 2010, at 9:21 AM, Aaron Watters wrote:
> >
> > Hi Richard,
> >
> > I work with Chuck at Rutgers.  I will try to answer your questions and
> Chuck
> > can
> > correct me if he feels the need.
> >
> > On Mon, Sep 27, 2010 at 4:20 PM, Richard C. Moyer II <rmoyer at umd.edu>
> wrote:
> >>
> >> Charles,
> >>
> >>        Here at Maryland we also use the eval group provider, but
> >> unfortunately, I cannot reproduce your error. Currently I'm in the
> middle of
> >> testing evaluation trunk, revision 70243, against our config and
> providers
> >> with the hope of migrating to sakai 2.7.
> >>
> >>        To help trouble shoot your situation, we'll need a little more
> >> details.
> >>
> >> 1. 'We're not seeing people in our evaluations' - are you signing on as
> a
> >> student and there are no evaluations or are signing on as an instructor
> or
> >> admin?
> >>
> >
> > We tried both.  The students see no evaluations and the admins see 0
> > students in the evaluations.
> >
> >> 2. 'Our evaluations come entirely from the Rutgers provider.' - are you
> >> building your evaluations outside of the sakai evaluation tool and
> importing
> >> in or are you building the evaluation using this tool and your groups,
> >> students, instructors, and TA come from your provider?
> >>
> >
> > We import the evaluation data directly into the database.
> >
> >>
> >> 3. 'old code' do you have a date or revision number?
> >>
> > I believe it was the 1.2 stable release.
> >
> >>
> >> 4. 'new code' do you have a date or revision number?
> >>
> >
> > 1.3 RC 2.
> >
> >>
> >> 5. what are the results from the Test EvalGroupProvider from the
> >> Administrate screen? As an admin, student & groupId.
> >> Are you getting  back Rutger's IDs or sakai IDs?
> >>
> >
> > "Unexpected error" with the following (abbreviated) traceback in
> > catalina.out
> >
> > 2010-09-28 09:05:03,200 WARN (RenderHandlerBracketer.java:107) -
> <Exception
> > rendering view: >
> > java.lang.IllegalArgumentException: Cannot add leaf component with ID
> > summary-link of class uk.org.ponder.rsf.components.UIInternalLink as a
> child
> > of component with ID   viewroot   of class
> uk.org.ponder.rsf.view.ViewRoot
> > since it would displace an existing child of the same name.
> >    Please remove the existing component first.
> >         at
> >
> uk.org.ponder.rsf.components.UIContainer.addComponent(UIContainer.java:142)
> >         at
> > uk.org.ponder.rsf.components.UIInternalLink.make(UIInternalLink.java:40)
> >         at
> >
> org.sakaiproject.evaluation.tool.producers.AdminTestEGProviderProducer.fillComponents(AdminTestEGProviderProducer.java:133)
> >         at
> >
> uk.org.ponder.rsf.view.support.ViewCollector.fillComponents(ViewCollector.java:56)....
> >
> >
> >>
> >> 6. are you using a UserDirectoryProvider?
> >
> > It doesn't look like it.  Should we be?
> > The Rutgers interface implements the following signature
> >
> > public class RutgersEvalGroupsProvider implements
> > org.sakaiproject.evaluation.providers.EvalGroupsProvider {...}
> >
> >>
> >> The summaryProducer, and supporting code has gone through several
> >> enhancements and re-writes over the years. It's possible that depending
> on
> >> how old your code is that your caught in a void that has since been
> fixed.
> >>
> >> Please let us know this info and perhaps we can dig a little deeper into
> >> the code.
> >
> > Thanks for your attention.  -- Aaron Watters (aaron at rutgers.edu)
> >
> > _______________________________________________
> > evaluation mailing list
> > evaluation at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/evaluation
> >
> > TO UNSUBSCRIBE: send email to
> evaluation-unsubscribe at collab.sakaiproject.org
> > with a subject of "unsubscribe"
> >
> > _______________________________________________
> > evaluation mailing list
> > evaluation at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/evaluation
> >
> > TO UNSUBSCRIBE: send email to
> evaluation-unsubscribe at collab.sakaiproject.org
> > with a subject of "unsubscribe"
> >
>
>
>
> --
> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/evaluation/attachments/20100928/7bb1bdd4/attachment.html 