[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch: Required fields on inital PR creation
From: |
Lars Henriksen |
Subject: |
Re: Patch: Required fields on inital PR creation |
Date: |
Sat, 26 Oct 2002 19:25:42 +0200 |
User-agent: |
Mutt/1.4i |
On Wed, Oct 16, 2002 at 10:42:46PM +1000, Andrew Gray wrote:
> > Please review (and hopefully accept) the following patch that fixes a bug
> > in the 'on-change require' functionality and also expands the Gnats grammar
> > to allow for "required input fields" upon initial PR creation.
>
> Thanks for submitting that patch. I will have a look at it in the next
> week and let you know if I have any questions.
The 'on-change require' is a very nice feature. Unfortunately it is only
documented in the code! A patch for the manual follows.
Back in May, Mel Hatzis submitted another very nice patch, concerned with
subject line parsing:
http://mail.gnu.org/pipermail/help-gnats/2002-May/002930.html
Are you considering that one for inclusion?
Lars Henriksen
Index: p-admin.texi
===================================================================
RCS file: /cvsroot/gnats/gnats/doc/p-admin.texi,v
retrieving revision 1.28
diff -u -r1.28 p-admin.texi
--- p-admin.texi 24 Oct 2002 12:46:56 -0000 1.28
+++ p-admin.texi 26 Oct 2002 17:15:24 -0000
@@ -690,21 +690,19 @@
The @code{on-change} subsection of a @code{fields} section specifies one
or more actions to be performed when the field value is edited by the
user. It has the general form
+
@example
on-change [ "query-expression" ] @{
address@hidden
@ @ [ add-audit-trail ]
address@hidden
@ @ [ audit-trail-format @{
@ @ @ @ format "formatstring"
@ @ @ @ [ fields @{ "fieldname" ... @} ]
@ @ @} ]
address@hidden
@ @ [ require-change-reason ]
address@hidden
@ @ [ set-field | append-to-field "fieldname" @{
@ @ @ @ "format-string" [ fieldlist ]
@ @ @} ]
+@ @ [ require @{ "fieldname" ... @} ]
@}
@end example
@@ -734,6 +732,14 @@
@code{append-to-field} option (the @code{read-only} option on a field is
ignored). However, the changes are subject to the usual field content
checks.
+
+The @code{require} option specifies that one or more fields must have
+a (non-blank) value when this field is changed.
+
+A field may be enforced to have a (non-blank) value at all times by
+including it in the set of fields required for the initial PR, see
address@hidden PR input fields}, as well as in the set of fields required
+on change of the field itself.
There is also a global @code{on-change} section that is executed once
for each PR edit. A typical use for such a section is to set the