Re: Subject header matching--once again

[Mel Hatzis]

On 11/04/2002 11:11 AM, Lars Henriksen wrote:
> On Sun, Nov 03, 2002 at 09:17:08PM -0800, Mel Hatzis wrote:
>
> > (snip)
> >
> > Building on your proposal, I suggest that it'd be even better if an
> > array of capture groups could be specified, each associated with a
> > field name. This would allow for fields other than 'category' on the
> > subject line.
> >
> > This could take the following form:
> >
> > subject-matching {
> >     "\\<PR[ \t#/]?([0-9]+)[ \t]?:(.*)"
> >     captured-fields {
> >           "Number" "Synopsis"
> >     }
> > }
>
>
> I like that, a nice, concise way of identifying the groups and their purpose,
> The built-in default would then become
>
>    subject-matching {
>        "\\<(PR[ \t#]?\\|([-\\w+.]+)/)([0-9]+)"
>        captured-fields {
>            "" "Category" "Number"
>        }
>    }
>
>
> > The example above would match subject lines of the form:
> >
> >  "PR 333 : missing subject-matching clause causes gnatsd to dump core"
> >
> > (verifying that the synopsis matched the PR number before accepting it
> > as a reference to PR 333)
>
>
> Would you allow any field name to appear in the list or just an exquisite
> selection? I am not well versed in the intricacies of gnatsd. Does the existing
> code allow a check of Synopsis as you suggest? There will, of course, have to
> be validity checks for each of the field types in the list.

The existing code would need to be modified to do the checking.
Currently, the code does a category search for the captured stuff
preceding the pr number - so it's fairly hardwired.
This could be addressed using 'find_field_index' and 'field_value'
for the fields in question.

One would also need to be careful to account for changes - for example,
if PR 333 is associated with category 'A' and someone updates it to
category 'B', a subject line of 'Re: A/333' should probably still
match PR 333 - this is currently what happens because the check for
category is independent of PR number.

This poses a problem for setups like my example which used 'Synopsis'
since, if the synopsis for PR 333 is modified, there is no way to
verify subject lines that reference the old synopsis. However, this
problem also applies to category, if one considers the possibility
that a category is deleted from the categories file.

Perhaps this is OK - if the category is deleted, it shouldn't surprise
anyone if subject lines with the old category no longer match. This is
a tougher argument to apply to a modified synopsis - since you're not
deleting the synopsis value, you're merely modifying it. With a category
modification, you can still do the verification, but with a synopsis
modification, you can't.

It all comes down to gnats-admin policy - the patch gives you the
flexibility to define your own policy. It won't protect against
ill-defined policy.

-Mel