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

Robert Sparks <> Wed, 22 February 2012 19:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8BFE121E8026 for <>; Wed, 22 Feb 2012 11:01:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eZQBQqjsfY3N for <>; Wed, 22 Feb 2012 11:01:02 -0800 (PST)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id A550021E8028 for <>; Wed, 22 Feb 2012 11:00:51 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q1MJ0mof097425 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 13:00:50 -0600 (CST) (envelope-from
Message-ID: <>
Date: Wed, 22 Feb 2012 13:00:48 -0600
From: Robert Sparks <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Ole Laursen <>
References: <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------070009000308040105060409"
Received-SPF: pass ( is authenticated by a trusted mechanism)
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 19:01:10 -0000

That's really surprising, and I want to double-check that we haven't 
accidentally lost something.

Your search was on the production code?

I'm seeing idinternal.area_acronym get used in trunk at
idindex/ def all_id2_entry(id):
./idindex/    if id.idinternal:
./idindex/        try:
./idindex/            area = id.idinternal.area_acronym

and in the search form

What are those replaced with in the new code?


On 2/22/12 11:18 AM, Ole Laursen wrote:
> 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.
> Ole