Closed Bug 142188 Opened 22 years ago Closed 9 years ago

Attachment search.

Categories

(Bugzilla :: Query/Bug List, enhancement)

2.15
enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: CodeMachine, Unassigned)

References

Details

We should have a feature that allows searching for attachments as well as bugs.
 This would act exactly the same as the query/buglist, except it would return
attachments rather than bugs.

There would be extra columns such as mime type, description, etc, and also all
of the bug columns for the owning bug would be available.

Similarly, you could search on both the existing bug restrictions available on
the bug page, but there would also be new restrictions for the attachments.

The attachment query template would look something like this:

[ Attachment Query Conditions ]
[ Bug Query Conditions (Existing Template) ]
[ Advanced Query Conditions (Existing Template) ]

The advanced query conditions would be changed so the lists of what can be
queried for a specific page is passed into the advanced query template from the
main query template.  Hence attachment query would have extra conditions, and
advanced query is potentially reusable elsewhere.  For example, maybe for user
searches in the administration section.

At the end of the day, this probably isn't too difficult - most of the code and
templates exist in the bug search, it's just a matter of abstracting them and
then adding to them.

Adding Gerv to CC for comments on the template reusability factor.
Why would you want to search for certain types of attachment (as opposed to bugs
with a certain type of attachment)?

"Give me (links to, presumably) all the attachments in the Bugzilla product
which are text/plain, patch and have second-review isn't really particularly
useful. Better to search for all bugs with such attachments, as if (in this
example) you are checking them in, you need to manipulate the bug anyway (and
check no-one's added a "wait a minute!" comment.)

Gerv
There are already attachment settings in the "Boolean chart". I think we should
just add Attachment number (and whatever elese) to the boolean chart and also
add the ability to search by attachment number in the quicksearch.

See bug 148562.
This is designed to be something different from bug search.  For example, it
allow a change several attachments at once feature across different bugs.
> For example, it allow a change several attachments at once feature across 
> different bugs.

Why is this a requirement? :-)

Gerv
For example, you might wish to add or remove an attachment status from
attachments that have or don't have certain attachment statuses, or fix up the
MIME type of a number of attachments using the same misspelled MIME type.
Is there a real-world scenario where this would have been useful to you personally? 

I can't see the second of those happening - a misspelt MIME type tends to get
fixed pretty quickly, because things don't work. And I can't think of a concrete
example for the first, unless you want to auto-review all your patches.

Gerv
MIME types mightn't be mispelled, but let's assume there are multiple MIME types
that are the same.  I think this has happened with XUL.  You might want to
consolidate them into one type.

As for attachment statuses, you're making big assumptions they're only useful
for review, when they're potentially a lot more useful.

But if you insist on discussing review, consider the situation where you have a
review keyword.  You might want to add a second-review keyword and split review
into first-review and second-review.  So you search for all attachments with
review, and bulk add the second-review status to these bugs.  Then you rename
review to first-review.
> Is there a real-world scenario where this would have been useful to you 
> personally? 

Seemingly not :-) But whatever - if someone writes this, I'm not going to oppose
it going in (unless said someone has 2.18 blockers on their plate). I still
think it would be of very limited use. <shrug>

Gerv

Priority: -- → P4
Target Milestone: --- → Future
Severity: normal → enhancement
Assignee: endico → nobody
Why not just search the attachments while searching the bug and return the bug 
if there are search term matches in one of the attachments.  I think that this 
would be good especially since many people are starting to put stack traces 
into file attachments, and it is a regular thing to do a search for a certain 
type of exception, but currently since the attachments aren't searched, these 
bugs are never reported even though they do have information pertaining to the 
search that was executed
*** Bug 236496 has been marked as a duplicate of this bug. ***
+1 for comment 9

Our users have been asking for the ability to include the contents of attachments as part of a search.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=104099

D.
I received an attachment link (without even an &action=...) and wanted to find its associated bug number
The fields that I see listed for attachments at https://bugzilla.mozilla.org/query.cgi are:
description, data, filename, mime type, is patch, is obsolete, is private

wouldn't it make sense to also have: number
per comment 2

Csaba Gabor from Vienna
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Future → ---
+1.  Eclipse.org suggests that users put error log and stack dumps into attachemnts, and those need to be searchable for the purpose of duplicate detection (bug 22353).
(In reply to comment #11)
> +1 for comment 9
> 
> Our users have been asking for the ability to include the contents of
> attachments as part of a search.

  You can already do that with the "Attachment data" boolean chart.
Thanks Max.  That sounds sufficient for Mylyn's needs.
Assignee: nobody → query-and-buglist
Priority: P4 → --
(In reply to comment #1)
> Why would you want to search for certain types of attachment (as opposed to
> bugs
> with a certain type of attachment)?

I agree with Gerv on this. I found a use case which seems not to be supported in Bugzilla: "search for bugs wich have an attachment submitted by me". Is there any bug tracking this feature? Thanks.
i agree that this has a very limited use-case.  without any recent action or a patch, this is wontfix.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.