Re: proclamation of intent

[Rick Macdonald <rickm@vsl.com>]

On Wed, 18 Aug 1999, Bob Manson wrote:

> >As a start, this format would want to be reasonable to parse as a list in
> >Tcl and perl. Perhaps we need client-selectable formats: tcl, perl, sh,
> >csh?
> 
> I could see that.  Want to make this as simple as possible to use, so
> having that sort of flexibility would be important.
> 
> I'm also not sure what exactly the clients would need to know, other
> than the names of the fields, their datatypes, and probably
> information about any restrictions on what values are valid (for enums
> the set of enumerated values, regexps, etc.)  Any further thoughts
> would be most helpful.
> 
> Oh, and there should be a human-readable description of the field.
> Don't want to forget that!

Yes, absolutely!

I feel that most of the "client hint" stuff that I sent out a while ago
still applies. IE which fields are to be shown in send PR, which trigger
email and change reasons and audit-trail entries, etc.

Have you seen all that? If not, I've pasted it at the bottom here.

I think these items could just be additional fields in your proposal. eg:

        field "Release-Note" {
                multitext
                query-default exact-regexp
		send-suppress
		edit-requires-reason
		edit-requires-audit-trail
		mandatory
        }

Or it could be like gnatsweb:

                flags "sendsuppress|editreason|audittrail|mandatory"

Or whatever; I'm easy.

> Ideally it would be possible for the client to get all of the data
> that describes a field, but presenting this in a useful way is going
> to be difficult (this quickly turnes into the traditional textual
> database metadata problem).

I don't see anything that the client _wounldn't_ want to get...

> >It sounds like you might just use regexps. An exact match of "RickM" would
> >need ^RickM$. An inexact (substring?) might be .*ick.*, *ick*, or just
> >ick?
> 
> Well, sometimes you really want to specify a string, even if it has
> regexp characters in it.  Obviously you can escape everything, but
> that can be painful (especially for an unknowing user that's calling a
> simple client like query-pr, and passing in abbreviations to search
> for).
> 
> I can also envision different search types for other data types,
> primarily numeric fields.  It'd be sorta nice to be able to select
> ranges of PRs easily (without having to explain complex regexps to
> users), or other types of numeric fields (numeric priorities?  version
> numbers or release qualifiers that are actual numbers?)  If you have
> that ability, then being able to specify string versus regexp searches
> seems like a natural extension.
> 
> As another example, perhaps we have several severity levels, and we
> want all PRs that are less than serious.  Yes, we can list all of the
> less-than-serious priorities out in a regexp search, but it's far
> easier and more accurate to specify that we want all PRs less than
> serious.

All of these cool things would be great.

> As for the string versus substring match, query-pr currently has
> varying behavior depending on what fields are being searched (some
> fields trying to match with an exact regexp, others allow matches with
> parts of the field).  I'm not sure if this is good or bad (the choices
> really seem quite arbitrary) but that's the way it's worked for a long
> time.  I'd rather give the user the ability to specify it, perhaps
> with defaults specified in the configuration file.

The current behaviour sucks; I can never remember when I need .*foo or
just foo!

> As for when this will be released... I was hoping to get something out
> this week, probably without any of the configuration file code but
> with a lot of the other changes I've been proposing.

Did you pick up my file-pr changes? gnatsweb is actually broken without
them.

BTW - I have no idea how many of the regular contributors subscribe to
this list. I hope they are all seeing this.

Here's the client hint stuff. I think just the functionality of
SUPPRESSED_FIELDS and FIELD_ALIASES would be obsolete with your great
additions.

The following are called "client hints" because front-end GNATS
programs such as gnatsweb and TkGnats are free to support any and all
of these configuration options. These options help give GNATS some
degree of user-customizable fields until such time as the core GNATS
code is modified for complete support.

In the absence of the client hints, the default behaviour of any
particular front-end client is up to the discretion of the client.

The format is comma-separated field names. For example:

	MANDATORY_FIELDS="Category,Originator,Synopsis,Description"

These optional parameters may be placed in the GNATS configuration
file gnats-db/gnatas-adm/config. GNATS itself ignores these options.

Where defaults are suggested, they are just a guideline to get the
same behaviour as the gnats clients send-pr and edit-pr.

Please note that GNATS currently has a limit of 255 characters per
line in the config file, including the parameter name.

FIELD_ALIASES:
        You can effectively rename any GNATS field with these aliases.
        The alias only affects the client interface. Behind the 
        scenes, the GNATS PR field still has the original name.

REQUIRE_AUDIT_TRAIL_ENTRY: 
        Edits to these fields trigger entries in the Audit-Trail.
        "none" signals no fields. "all" signals all fields.

REQUIRE_AUDIT_TRAIL_REASON: 
        Edits to one or more of these fields triggers the
        prompt of one reason for all changes for the Audit-Trail.
        "none" signals no fields. "all" signals all fields.

REQUIRE_AUDIT_TRAIL_EMAIL: 
        Edits to one or more of these fields trigger the 
        sending of email notification.
        "none" signals no fields. "all" signals all fields.

MANDATORY_FIELDS:
        SendPR will insist that new PRs have values for these fields.
        EditPR will insist that editied PRs have values for these fields.
        "none" signals no fields. "all" signals all fields, but doesn't
        include Audit-Trail, Unformatted or Release-Note in EditPR
	because these fields are usually added by GNATS and are often
        blank for the first part of a PRs life. You can always add these
        fields if you wish.

SUPPRESSED_FIELDS: 
        Fields to suppress from view in all front-end views.
        SUPPRESSED_FIELDS override MANDATORY_FIELDS if a field
        appears in both lists.

SUPPRESSED_SEND_FIELDS:  See "unless" options below.
        Fields not to present in SendPR.
        Format: field[(unless)]
	Default: State,Responsible,Release-Note,Unformatted,Audit-Trail
        Example: State,Responsible(edit),Release-Note,Audit-Trail

SUPPRESSED_EDIT_FIELDS:  See "unless" options below.
        Fields not to present, or to present read-only, in EditPR.
	It is suggested that front-ends do not allow editing Arrival-Date,
        Last-Modified and Closed-Date, since these are maintained by
GNATS.
        Format: field[(unless)]
        Example: Audit-Trail(admin)

SUPPRESS "unless" options:
        Finer control over the showing of fields in SendPR and EditPR.
        In SendPR, the field is suppressed. 
        In EditPR, the field is suppressed or shown read-only, at the
                   discression or configuration of the front-end.

        Suppress fields:

        user      - unless the user of the front-end asks for it.
        edit      - unless the user has edit access.
        edituser  - unless the user has edit access and
                    the user of the the front-end asks for it.   
        admin     - unless the user has admin access.
        adminuser - unless the user has admin access and
                    the user of the the front-end asks for it.   

...RickM...