[Contrib: Evaluation System] provider not being called

Aaron Zeckoski azeckoski at unicon.net
Tue Sep 28 07:42:24 PDT 2010


Sakai will assign the ids when the users are resolved by the UDS
lookup. It does not matter if they had logged in before or not.

-AZ


On Tue, Sep 28, 2010 at 9:37 AM, Aaron Watters <aaron.watters at gmail.com> wrote:
> 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
>
>



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


More information about the evaluation mailing list