Users want to enter a CR once for several categories

[Jo A Wahle]

I've had a challenging request from some of my users. We have a number of projects that are separate, but interconnected, and sometimes the same issue affects several projects. Currently, the person submitting the request has to Create several PRs (all users use gnatsweb) and retype the information for each one. (Depending on your browser settings, it may save the form fill-in values, but not for multi-line form fields, and that doesn't help with enumerated fields.) How could I provide that kind of functionality?

I've thought about how I could have one PR that applies to multiple categories. That has the drawback that there is only one State field, for instance, so it assumes that all projects proceed with the change in lock-step. Since gnats stores the PRs in directories for each Category, there would have to be a "main" category, so I tried an "Additional-Categories" field, but I'm having trouble with the multi-enumerated-in-file type. (I'm not sure whether I can get the mail-formats to work the way I want if I can get past the other hurdles.) Turns out maybe that's not what the users wanted (I thought that's what they asked for) because then all the projects would have to share the fields.

I've thought about some way to relate PRs to each other. The gnatsweb code looks for a special "related-prs" field, which I thought might be a starting point. It might work for the very last PR, to connect it to all the previous ones, but somehow the previously-entered PRs need to be related to the ones added later, and then there's the issue of keeping all of the lists in sync. Plus, that still doesn't help with the initial creation of the PRs, because the user still has to Create each one. I might be able to add a hack to gnatsweb that could take some form information and submit multiple PRs, but that doesn't hook them all together, because I have to get the PRs back for all the other PRs in order to relate them... as long as I'm writing perl CGI, I suppose I could create several, get back all the PR Numbers, and then edit all of those to include all of the other PRs... ugh. I suppose I wouldn't have to relate them directly through the PR Numbers - maybe if they have the same "Synopsis", assume they're related? That doesn't sound like an ugly hack at all.

Other suggestions?

--
Jo Wahle, Software Engineer, Engineering Support, SAIC
(Science Applications International Corporation – www.saic.com)
Contractor to U.S. Geological Survey – EROS, Sioux Falls SD 57198
(Earth Resources Observation and Science – eros.usgs.gov)

_______________________________________________
Help-gnats mailing list
Help-gnats@...
http://lists.gnu.org/mailman/listinfo/help-gnats

[Chad Walstrom]

Jo A Wahle <wahle@...> wrote:
    Jo> I've thought about some way to relate PRs to each other. The
    Jo> gnatsweb code looks for a special "related-prs" field, which I
    Jo> thought might be a starting point. It might work for the very
    Jo> last PR, to connect it to all the previous ones, but somehow the
    Jo> previously-entered PRs need to be related to the ones added
    Jo> later, and then there's the issue of keeping all of the lists in
    Jo> sync. Plus, that still doesn't help with the initial creation of
    Jo> the PRs, because the user still has to Create each one. I might
    Jo> be able to add a hack to gnatsweb that could take some form
    Jo> information and submit multiple PRs, but that doesn't hook them
    Jo> all together, because I have to get the PRs back for all the
    Jo> other PRs in

What about two new fields: Parent and Children.  Here, you can add PR's
in the syntax PR#NNNN, which gnatsweb should pick up and URL'izes.  Then
add an [Add Child] submission button that clones a portion of the
Description or Synopsis and automatically fills in the Parent field.
Once that functionality is set up for the singular instance, you could
construct a special [Add Children] submission button to specify multiple
categories in one fell swoop.  I'm not sure how beneficial that might
be, though.  You still might like to specify different responsibility
for different children.

The parent PR could remain in an open state until all of the children
are closed.  Having a Related-PRs field wouldn't be a bad idea for those
instances where a Parent-Child relationship isn't necessary.  I don't
think I would worry about trying to synchronize it with any other PR's
Related-PRs field.

An interesting AJAX hack would be to retrieve Category, Synopsis, and
State info when you mouse-over a PR's URL.

Other nice features to have would be for "clone" and "merge"
functionality...



_______________________________________________
Help-gnats mailing list
Help-gnats@...
http://lists.gnu.org/mailman/listinfo/help-gnats