Users want to enter a CR once for several categories

This is a multipart message in MIME format.
--===============1901900100==
Content-Type: multipart/alternative;
	boundary="=_alternative 007409AA862572B3_="

This is a multipart message in MIME format.
--=_alternative 007409AA862572B3_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

I've had a challenging request from some of my users. We have a number of=20
projects that are separate, but interconnected, and sometimes the same=20
issue affects several projects. Currently, the person submitting the=20
request has to Create several PRs (all users use gnatsweb) and retype the=20
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=20
doesn't help with enumerated fields.) How could I provide that kind of=20
functionality?

I've thought about how I could have one PR that applies to multiple=20
categories. That has the drawback that there is only one State field, for=20
instance, so it assumes that all projects proceed with the change in=20
lock-step. Since gnats stores the PRs in directories for each Category,=20
there would have to be a "main" category, so I tried an=20
"Additional-Categories" field, but I'm having trouble with the=20
multi-enumerated-in-file type. (I'm not sure whether I can get the=20
mail-formats to work the way I want if I can get past the other hurdles.)=20
Turns out maybe that's not what the users wanted (I thought that's what=20
they asked for) because then all the projects would have to share the=20
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=20
starting point. It might work for the very last PR, to connect it to all=20
the previous ones, but somehow the previously-entered PRs need to be=20
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=20
creation of the PRs, because the user still has to Create each one. I=20
might be able to add a hack to gnatsweb that could take some form=20
information and submit multiple PRs, but that doesn't hook them all=20
together, because I have to get the PRs back for all the other PRs in=20
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=20
them directly through the PR Numbers - maybe if they have the same=20
"Synopsis", assume they're related? That doesn't sound like an ugly hack=20
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)

--=_alternative 007409AA862572B3_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


<br><font size=3D2 face=3D"sans-serif">I've had a challenging request from
some of my users. We have a number of projects that are separate, but inter=
connected,
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 setting=
s,
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?</font>
<br>
<br><font size=3D2 face=3D"sans-serif">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 directo=
ries
for each Category, there would have to be a &quot;main&quot; category,
so I tried an &quot;Additional-Categories&quot; field, but I'm having troub=
le
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 field=
s.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">I've thought about some way to relate
PRs to each other. The gnatsweb code looks for a special &quot;related-prs&=
quot;
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 previ=
ously-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 togethe=
r,
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 &quot;Synopsis&quot;,
assume they're related? That doesn't sound like an ugly hack at all.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">Other suggestions?</font>
<br><font size=3D2 face=3D"sans-serif"><br>
--<br>
Jo Wahle, Software Engineer, Engineering Support, SAIC<br>
(Science Applications International Corporation &#8211; www.saic.com)<br>
Contractor to U.S. Geological Survey &#8211; EROS, Sioux Falls SD 57198<br>
 (Earth Resources Observation and Science &#8211; eros.usgs.gov)<br>
</font>
--=_alternative 007409AA862572B3_=--



--===============1901900100==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Help-gnats mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-gnats

--===============1901900100==--