[Building Sakai] Turnitin issue with new users

[Bryan Bakotich]

Steve,

That is a correct assumption. We have the one instructor defined in
sakai.properties that does everything and we are using Assignments 1. We
would like to move to a setup where we don't have to use the 1 instructor
approach. Is this the way things are moving in the trunk? What is the
targeted sakai version for the trunk code?

-Bryan

On Tue, Apr 26, 2011 at 12:01 PM, Steven Githens <swgithen at mtu.edu> wrote:

>  Hi Bryan,
>
> Sorry, I'm behind on email.
>
> I've fixed a few issues dealing with this in trunk, and am hoping to cut a
> tag of it soon since we've been testing it for a few weeks.
>
> I'm assuming you on a setup with a single instructor controlling all the
> assignments (with the sakai.properties for default instructor xyzed
> settings) and with Assignments 1 at the moment?
>
> Cheers,
> Steve
>
>
> On 04/08/2011 05:51 PM, Bryan Bakotich wrote:
>
> Hi all,
>
>  We have seen quite a few errors while submitting papers to Turnitin
> recently. The error listed in the database is this:
>
>  *Submission Error: There was an error building up the user session data
> to submit the paper.  Please verify the user information being used.(250)*
>
>  The first time we ever saw this error was at the beginning of this March.
> Since then we've seen it 60+ times. I can reproduce this error by submitting
> an attachment to a Turnitin assignment as a student that has never used
> Turnitin before. If I set the status of the records back to 1 and try to
> submit them a second time it works fine. So the issue seems to have to do
> with the user being created with the web service call to Turnitin.
>
>  I have contacted our Turnitin rep and worked back and forth with an
> engineer for a while and was unable to modify the webservice calls to make
> this error go away. They told me to use a session-id in the api calls and
> that should fix the issue. After that didn't work I sent them all the
> information from the calls that were being made and this is what they told
> me:
>
>  *It  appears that the join class call is happening before the database
> has had a chance to propagate the information from the master to the slave
> databases from the create user call, even while using the session id.  I'll
> let you know if we discover anything.  Sorry I don't have anything more
> concrete for you right now.*
>
>  The only other suggestion they gave me was putting a delay in between the
> join class call and the submit paper call. Has anyone else run into this
> issue recently and is there a solution to it other than a delay or should I
> just put in a 3-5 second delay like they suggested? Thanks for any help.
>
>  -Bryan
>
> --
> Bryan Bakotich
> Open Source Implementation Specialist
> Digital Media Center, Information & Technology Services
> Pacific Lutheran University
> Tacoma, WA 98447-0013
> Phone: 253-536-5021
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.orghttp://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>
>
> _______________________________________________
> 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"
>



-- 
Bryan Bakotich
Open Source Implementation Specialist
Digital Media Center, Information & Technology Services
Pacific Lutheran University
Tacoma, WA 98447-0013
Phone: 253-536-5021
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110426/0aa8aee5/attachment.html