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

Ole Laursen <olau@iola.dk> Wed, 22 February 2012 17:19 UTC

Return-Path: <olau@iola.dk>
X-Original-To: iola-conversion-tool@ietfa.amsl.com
Delivered-To: iola-conversion-tool@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8889F21F8585 for <iola-conversion-tool@ietfa.amsl.com>; Wed, 22 Feb 2012 09:19:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.676
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZgxt8-GK5yb for <iola-conversion-tool@ietfa.amsl.com>; Wed, 22 Feb 2012 09:19:34 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0826921F8514 for <iola-conversion-tool@ietf.org>; Wed, 22 Feb 2012 09:19:15 -0800 (PST)
Received: by vcbfk14 with SMTP id fk14so226977vcb.31 for <iola-conversion-tool@ietf.org>; Wed, 22 Feb 2012 09:19:15 -0800 (PST)
Received-SPF: pass (google.com: domain of olau@iola.dk designates 10.52.92.47 as permitted sender) client-ip=10.52.92.47;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of olau@iola.dk designates 10.52.92.47 as permitted sender) smtp.mail=olau@iola.dk
Received: from mr.google.com ([10.52.92.47]) by 10.52.92.47 with SMTP id cj15mr16801899vdb.11.1329931155483 (num_hops = 1); Wed, 22 Feb 2012 09:19:15 -0800 (PST)
Received: by 10.52.92.47 with SMTP id cj15mr13644334vdb.11.1329931155282; Wed, 22 Feb 2012 09:19:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.96.130 with HTTP; Wed, 22 Feb 2012 09:18:55 -0800 (PST)
In-Reply-To: <4F4415E7.9080608@nostrum.com>
References: <4F4415E7.9080608@nostrum.com>
From: Ole Laursen <olau@iola.dk>
Date: Wed, 22 Feb 2012 18:18:55 +0100
Message-ID: <CANb2OvKXRUarNY-Vp+CkA+7P5FZ1=_OfqyO67gOnKfx2bAARCQ@mail.gmail.com>
To: Robert Sparks <rjsparks@nostrum.com>
Content-Type: multipart/alternative; boundary=20cf3071c6ae16191904b990ba68
X-Gm-Message-State: ALoCoQlFYdM4KS4dpoW1YE5CZmBpJaZ218qp2AwNo/E9blebJRG7TiUzRn9OuegA0z5Su1g9J36v
Cc: iola-conversion-tool@ietf.org
Subject: Re: [iola-conversion-tool] Bug when Adding a document to the tracker
X-BeenThere: iola-conversion-tool@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the IOLA / DB Schema Conversion Tool Project <iola-conversion-tool.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iola-conversion-tool>, <mailto:iola-conversion-tool-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/iola-conversion-tool>
List-Post: <mailto:iola-conversion-tool@ietf.org>
List-Help: <mailto:iola-conversion-tool-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iola-conversion-tool>, <mailto:iola-conversion-tool-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Feb 2012 17:19:36 -0000

2012/2/21 Robert Sparks <rjsparks@nostrum.com>

> 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