Closed Bug 37008 Opened 24 years ago Closed 19 years ago

Ability to add 'testcase' or 'patch' keywords when adding an attachment

Categories

(Bugzilla :: Attachments & Requests, enhancement, P3)

Product:
Bugzilla
Component:
Attachments & Requests
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: sicking, Assigned: myk)

Details

It would be nice if we were able to add the 'testcase' or 'patch' keywords at 
the add-attachment page. This would reduce spam (since only one mail is sent 
out) and would also make more people remember to add these keywords.
I think the ideal solution to this is to not make attachments an action, but
rather make it so that after an attachment you go back to the show_bug.cgi page
and have to commit the change (or alternatively, put the attachment panel in the
page itself).

That way you can attach multiple files in one action, or do an attachment in the
same action as any other change.

I think the best long term solution is to change Bugzilla so these keywords are
rendered unnecessary by advanced querying.  These keywords are mozilla.org
specific so it's hard to make them automatically added or anything similar.
since the keywords are in their own table...  how about adding a groupset column 
to that table, and allowing someone with editgroups or superuser privs to set the 
groupset bits on a given keyword.  Then you could specify certain keywords that 
anyone could set, or ones that only certain people can set, etc.

assigning to me since this is a schema change idea
Assignee: tara → cyeh
Maybe one way of doing this would be to have the ability to add keywords to
attachmens (or just classify them by selecting one from a list). That way we
could also do searches for all attachments that are testcases for css1 bugs, or
pathces for netlib etc.

"There's no end to the possibilities" :-)
How about if we change the "add an attachment" from a link to a button.  Do the 
same with it that we currently do with the boolean forms at the bottom when you 
click the And or Or buttons...  that is, reload the form with additional 
controls on it (the elements for adding an attachment).  Then it all goes in 
with the same Commit.
The "Create a new attachment" link already takes you to a page with a bunch of 
radio buttons for "what type of file is this". All we'd need to do is add a 
selection for a test case (there is already one for patches) and have those two 
automatically add the keyword. Or since several of the non-patch types could be 
test cases then perhaps the testcase option should be an extra checkbox on that 
same page.
I want to echo the sentiment that while a nifty idea, the use of the 'patch' 
keyword is mozilla.org specific and somewhat redundant given you can search for 
attachments for a Product/Component in the main query page.

Why is mozilla.org using the 'patch' keyword to start with? Is it because the 
query page UI for finding attachments is too confusing?
"Confusing"? Does anyone even know it's there?  I didn't.

Now that I know about it, I couldn't get the "Attachment is Patch" choice to 
work at all. I had better luck searching by description, but not everyone flags 
patches as such ("diffs to x" was also popular) and the test cases were also 
not flagged very consistently.
The only person i know who uses that is Endico, and I suspect she did direct 
queries.  We need a good set of interfaces

I've found that direct queries using techbot1 (irc.mozilla.org) is often easier 
than using the html interface we have.  Complete documentation about all 
parameters and a spiffy xul interface would be a good start.

Before we do that, i'd like a way to pass &totals=only [so that i can do 
queries w/o getting the results], and a way to &errors=suppress|ignore|<carp> 
[if I do &keywords=notreal+rtm&keywords_type=anywords&errors=ignore i'd like to 
get output from rtm even though notreal isn't a keyword.  Yes I know i should 
file bugs for this, but i have Mozilla FE work w/ a deadline.  I'll help after 
that stuff commits.
I usually use "if attachment data > 0" to look for patches. I'm still not 
terribly inclined to automatically attach keywords to patches, nor am I all that 
enthused about putting a UI in there to allow for it. If you give someone a 
checkbox you leave it in the hands of a user to click on it or not. This causes 
inconsistant usage of the keyword and may cause you to miss bugs with patches 
where people didn't see the checkbox or forgot to click it, or whatever.


Ok, how about a checkbox on the other end?

<x> Search for bugs w/ patches.
where that expands to the search you're using.

Then we can resolve this as fixed since there'd be an easy way of finding it.
Again i'd prefer for that to be a flag which can be lazily passed to the query 
backend and expanded.
"if attachment data > 0" gives me all the bugs with screen shots or 
other test cases attached, I want patches. One of the radio buttons on the 
attachment page says that the attached is a patch so that data is in the system 
somewhere. There is even a "Attachment is patch" selection in the query page, 
but I can't figure out how to make it work. If it worked it would go a long way 
toward eliminating the need for this bug. 

"testcase" could then perhaps be deduced by looking for bugs that have 
attachment data and are NOT patches. You'd still get a bunch of screen shots 
that aren't really test cases though.
The problem I wanted to solve was that many people didn't add the 'patch' 
or 'testcase' keyword when adding attachments.

This makes it hard to find bugs that have those kinds of attachments (nither I 
knew about "Attachment is Patch", but since it dosn't work anyway...)

My new proposal to solve this is to make it possible to classify attachments. 
Just add a dropdown on the attachment page which is db driven. Good attachment 
classes for mozilla could be¨'patch', 'testcase', 'screenshot' and 'proposed 
spec'. This way it is in no way mozilla specific (not any more then keywords 
for bugs are), and it would be possible to do rather nice queries...

Why don't we just have the attachment bits of the form in the bug page itself? 
That way users could make any other necessary changes to the bug (whether these 
be adding keywords, or making comments, or changing severity, or whatever) at the 
same time as they added their attachment.

Considering the number of times people have said `I'm about to attach a 
screenshot which shows ...', or `The file I've just attached is ...', this would 
appear to have many other benefits as well.

I'd go for Matthew's idea of the "Create Attachments" link reloading the form 
with added attachment UI. I'd be very against that UI being there by default, 
but his idea permits you to make arbitrary changes at the same time.

For a bonus, the reload would preserve info already changed ;-)

Gerv
Just moving "Create Attachments" to the mainform wouldn't solve this bug. 
People would still forget to add the 'testcase' keyword.

So still propose idea of classification of attatchments. Using that the 'patch' 
and 'testcase' keywords could be completly removed and we could do queries 
rather nice bugzilla queries.

I guess we could also move the "Create Attachments" to the main form if that 
makes everybody happier :-)
On reflection (and as I noted in n.p.m.seamonkey), cluttering the bug form with 
the attachments UI is probably a bad idea. Instead, I think Bugzilla should do 
what Hotmail does: take you to a separate page for the attachment(s), and then 
take you back to the bug report when done. When you went back to the bug report, 
none of your changes would have been committed yet, but the changes you had been 
making before you decided to make an attachment would still be there; this could 
be done by storing them as hidden form elements on the attachments page, or by 
using a temporary database tagged by an identifier in the URL of the attachments 
page.
Target Milestone: --- → Future
Taking all of cyeh's Bugzilla bugs.
Assignee: Chris.Yeh → justdave
->New product Bugzilla
Assignee: justdave → myk
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → unspecified
we haveconfigurable attachment status and type now. the patch keyword is no
longer necessary and should probably go away.  "attachment is patch" is settable
on attachment creation and is queriable in the boolean/advanced query. It may
make sense to add the attachment type "is testcase" giving us "is patch","is
testcase" and "is obsolete" as the attachment types.
Component: Creating/Changing Bugs → attachment and request management
This should probably be closed out now. Installations that want this (b.m.o
possibly) could add a 'testcase' or 'patch' attachment flag and do it this way.
A far better solution then using keywords.
Indeed.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
Target Milestone: Future → ---
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.