From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10487 invoked from network); 25 Sep 2002 15:43:36 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 25 Sep 2002 15:43:36 -0000 Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17uEK4-0003CL-00; Wed, 25 Sep 2002 11:43:32 -0400 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17uEJ0-000311-00 for help-gnats@gnu.org; Wed, 25 Sep 2002 11:42:26 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17uEIy-00030h-00 for help-gnats@gnu.org; Wed, 25 Sep 2002 11:42:25 -0400 Received: from cluster2.netman.dk ([193.88.72.48]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17uEIx-00030N-00 for help-gnats@gnu.org; Wed, 25 Sep 2002 11:42:23 -0400 Received: (from lh@localhost) by cluster2.netman.dk (8.11.4/8.11.4) id g8PFdfM1152428; Wed, 25 Sep 2002 17:39:41 +0200 (MEST) From: Lars Henriksen To: Robert Lupton the Good Cc: help-gnats@gnu.org, Yngve Svendsen Subject: Re: Patch for gnatsweb.pl Message-ID: <20020925153941.GD1135030@cluster2.netman.dk> References: <15749.57217.976539.558063@wire7.Princeton.EDU> <20020922184733.GA1071317@cluster2.netman.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020922184733.GA1071317@cluster2.netman.dk> User-Agent: Mutt/1.4i Sender: help-gnats-admin@gnu.org Errors-To: help-gnats-admin@gnu.org X-BeenThere: help-gnats@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General discussion about GNU GNATS List-Archive: Date: Wed, 25 Sep 2002 11:18:00 -0000 X-SW-Source: 2002-q3/txt/msg00125.txt.bz2 Hello, Since no one else will, I'll comment myself ;-) On Sun, Sep 22, 2002 at 08:47:33PM +0200, Lars Henriksen wrote: > On Mon, Sep 16, 2002 at 09:41:21AM -0400, Robert Lupton the Good wrote: > > > (This is my `patch.3b') > [snip] > > 1/ requires exact matches for field names selected using > > scrolling lists. For example, we have a "Scheduled" field that > > has entries "approved" and "notapproved"; without this patch > > selecting "approved" gets "notapproved" too. The reason is that > > gnatsweb uses a ~ match in its query, and this seems reasonable. > > > > This patch adds explicit "^" and "$" to the fields, and then > > adds code so that the user doesn't see them (Note: this doesn't > > work very elegantly with my "load stored query" patch that > > I sent to the list a few days ago. This problem is fixed in > > a later patch that I'll send today). > > This is a clever trick, but I believe there is more to it. I've realised that there is even more to it than I thought at first. Robert Lupton's patch as well as mine breaks backward compatibility: bookmarked and stored queries may stop working or behave differently. According to comments in the gnatsweb code, that is also what has kept the parameter/field/lower/upper case confusion from being dealt with and field2param() and param2field() from disappearing. I have spent some time on figuring out the use of (dbconfig) field names versus form parameter (lower case) versions. It is not too difficult to eliminate the parameter/field conversion entirely and use dbconfig names (I have a patch) but again, not without breaking some existing bookmarked and stored queries. Do we want to (must we) keep backward combatibility? With gnatsweb 3.*? With earlier gnatsweb 4 versions? As far as I can see from some bookmarks produced by 3.113, compatibility with that version is already broken (I have seen some "arrivedbefore=" or "modifiedafter=" query parameters that are not recognised by gnatsweb 4). Are we stuck with the broken logic in the following piece of code which means that list selection on the advanced query page is interpreted as a regular expression match whereas list selection on the query page is interpreted as a string match (e.g. selecting state = critical will also return non-critical from the advanced query page, but not from the query page)? > This affects the following piece of code in submitquery(): > > # Most (?) people expect queries on enums to be of the > # exact, not the substring type. > if (fieldinfo($field, 'fieldtype') =~ "enum|multienum") > { > $subexp = appendexpr ($subexp, '|', "$ucfield==\"$sval\""); > } > else > { > $subexp = appendexpr ($subexp, '|', "$ucfield~\"$sval\""); > } > > ... > The upshot is that the if-clause is taken from query_page() (except for > Synopsis), the else-clause from advanced_query_page() whether the field > type is enumerated or not. If that was the intention, the comments and the > if-expression are misleading to put it mildly! What do you think? Lars Henriksen _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://mail.gnu.org/mailman/listinfo/help-gnats