Re: [iola-conversion-tool] Bug when Adding a document to the tracker

Ole Laursen <> Wed, 22 February 2012 17:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8889F21F8585 for <>; Wed, 22 Feb 2012 09:19:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.676
X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PZgxt8-GK5yb for <>; Wed, 22 Feb 2012 09:19:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0826921F8514 for <>; Wed, 22 Feb 2012 09:19:15 -0800 (PST)
Received: by vcbfk14 with SMTP id fk14so226977vcb.31 for <>; Wed, 22 Feb 2012 09:19:15 -0800 (PST)
Received-SPF: pass ( domain of designates as permitted sender) client-ip=;
Authentication-Results:; spf=pass ( domain of designates as permitted sender)
Received: from ([]) by with SMTP id cj15mr16801899vdb.11.1329931155483 (num_hops = 1); Wed, 22 Feb 2012 09:19:15 -0800 (PST)
Received: by with SMTP id cj15mr13644334vdb.11.1329931155282; Wed, 22 Feb 2012 09:19:15 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 22 Feb 2012 09:18:55 -0800 (PST)
In-Reply-To: <>
References: <>
From: Ole Laursen <>
Date: Wed, 22 Feb 2012 18:18:55 +0100
Message-ID: <>
To: Robert Sparks <>
Content-Type: multipart/alternative; boundary=20cf3071c6ae16191904b990ba68
X-Gm-Message-State: ALoCoQlFYdM4KS4dpoW1YE5CZmBpJaZ218qp2AwNo/E9blebJRG7TiUzRn9OuegA0z5Su1g9J36v
Subject: Re: [iola-conversion-tool] Bug when Adding a document to the tracker
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the IOLA / DB Schema Conversion Tool Project <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Feb 2012 17:19:36 -0000

2012/2/21 Robert Sparks <>

> The biggest is that the form didn't ask for the area the document should
> be associated with.
> It occasionally happens that an AD from outside the area takes the
> shepherd role for a document, so
> you can't infer this from which AD is assigned.

Right. At the moment, we don't store an area at all. Grepping for it, the
only place I managed to find using the attribute apart from the edit form
is the agenda document template where the proxy wrapper will infer the area
from the WG (if there's a WG) or else from the shepherding AD.

The search page looks for the area of the WG in the old schema if you do a
search for area, not the area attribute which is perhaps not surprising if
it's only set for documents in the IESG process.

So do you think this is a problem still?

> Less important, (but important none the less), the fields are initially
> populated very badly.

That's odd. Or rather, it's odd that how it worked before because AFAICT
from the documentation to Django, it shouldn't have. :) It could possibly
be because of the new Django version. In any case, I think I managed to fix
this now.