[prev in list] [next in list] [prev in thread] [next in thread] 

List:       markus-dev
Subject:    Re: Too many redirects
From:       Mike Conley <mike.d.conley () gmail ! com>
Date:       2010-09-22 18:03:53
Message-ID: AANLkTinYL=G6hbgRWXd0phokjyY=cRBCyrsCCPYUnwUL () mail ! gmail ! com
[Download RAW message or body]

Byron:

Alright - I've removed the duplicate Groups, and the students should
now have membership in a group.

Let us know if this helps, or what else you run in to,

-Mike

On Wed, Sep 22, 2010 at 1:51 PM, Mike Conley <mike.d.conley@gmail.com> wrote:
> Byron:
>
> Alright, I've removed the newer group for one of the users, and
> attempted to add them to their older group.
>
> The following error gets dumped out:
>
> Traceback (most recent call last):
>  File "./markusSubmission.py", line 30, in <module>
>    assDir = sys.argv[3]
> IndexError: list index out of range
> Usage: /u/isg/bin/submit/submit_pub_test_hook course_name assign full_userid ...
>
> Looking at this, I'd have to guess that you've added a post-commit
> hook that might be getting some invalid input.
>
> Regardless, the Grouping for the one user was successfully created,
> and their membership in the group was created.
>
> I will do the same with the other users, and we'll see where we stand.
>
> -Mike
>
> On Wed, Sep 22, 2010 at 1:28 PM, Mike Conley <mike.d.conley@gmail.com> wrote:
>> Byron:
>>
>>> No.  But I did understand that I was supposed to create new groups for these students
>>> (using the MarkUs interface), which I tried for most.
>>
>> It's disconcerting that MarkUs let you create those new groups in the
>> first place, if older ones already existed.
>>
>> What I'll do, is generate a list of students who have duplicate
>> groups.  Then, with your permission, I'll remove the newer groups.
>>
>> If the old problem recurs, then I think the solution of creating new
>> groups was just masking a bigger problem.  Now that I have console
>> access, diagnosing and solving that older problem (if it recurs) will
>> be considerably easier.
>>
>> -Mike
>>
>> On Wed, Sep 22, 2010 at 1:19 PM, Byron Weber Becker
>> <bwbecker@cs.uwaterloo.ca> wrote:
>>>
>>> On 2010-09-22, at 1:13 PM, Mike Conley wrote:
>>>
>>>> Byron / all:
>>>>
>>>> Ok, I've done a little investigating.
>>>>
>>>> Byron gave me shell access to the machine that MarkUs is running on,
>>>> and a list of students who are experiencing the problem.
>>>>
>>>> I used the console to browse around the database a little, and it
>>>> looks like the users that are having problems have *two* groups each.
>>>> Both groups have the same group_name.
>>>>
>>>> Normally, this is not possible.  The Group model uses
>>>> validates_uniqueness_of :group_name to prevent this sort of collision.
>>>>
>>>> Byron:  has the database been edited manually?
>>>
>>> No.  But I did understand that I was supposed to create new groups for these students
>>> (using the MarkUs interface), which I tried for most.  I did this for
>>> aemausko, cbdpushp, ssuh, and jwzleong for assignment a00.  That seemed to solve the
>>> problem they had of getting an exception displayed to them.
>>>
>>> I tried doing that again for a01 but it failed, as described in a previous message.
>>>
>>>> Am I OK to remove the
>>>> duplicates?  Is it safe to assume that I'll want to remove the *newer*
>>>> duplicates?
>>>
>>> I suppose so.  We should have other copies of their materials.
>>> Given that some of them were having errors on the first assignment and that
>>> adding a new group *seemed* to fix it, I'm not sure that deleting the newer
>>> group is the right one.  Perhaps all groups for these students should be removed?
>>>
>>> Byron
>>>
>>> ---------------------------------------------------------
>>> Byron Weber Becker             Voice: 519-888-4567 x34661
>>> School of Computer Science       Fax: 519-885-1208
>>> University of Waterloo        Office: DC3105
>>> Waterloo, ON  N2L 3G1
>>>
>>>
>>
>>
>>
>> --
>> http://www.mikeconley.ca
>>
>
>
>
> --
> http://www.mikeconley.ca
>



-- 
http://www.mikeconley.ca

[prev in list] [next in list] [prev in thread] [next in thread]