Closed Bug 1539302 Opened 5 years ago Closed 5 years ago

Add "attachment is patch" field to bug

Categories

(bugzilla.mozilla.org :: Search, enhancement)

Production
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: emceeaich, Assigned: dylan)

Details

Attachments

(2 files)

It's possible to filter bug searches on those bug with a patch (ex. https://mzl.la/2Fyjgzj) but not to indicate in a bug list if a bug has a patch.

Make attachment is patch available in search results in all formats.

We can do this, but…

  • Emma’s search queries include “Attachment is patch: true” but it’s actually not working. For example, Bug 1518058 comes first but it doesn’t have any patch.
  • As you know we have migrated to Phablicator, and some products including BMO are using GitHub. It means the number of traditional patches is decreasing. Should we count Phablicator and GitHub PRs as patches?
Assignee: nobody → kohei.yoshino
Status: NEW → ASSIGNED
Component: Bug Creation/Editing → Search
Flags: needinfo?(ehumphries)

Yes, Phab and GitHub PRs are the patches of interest.

Phab patches are handled through the plugin, if I recall right.

Should GitHub PRs follow a similar path instead of creating text attachment with the link to the PR?

Flags: needinfo?(ehumphries)

Phab, GitHub and legacy MozReview requests are all handled in the BMO extension, and those are technically links written in a text attachment that can be distinguished with the text/x-phabricator-request, text/x-github-pull-request or text/x-review-board-request MIME type. On the modal bug page, these attachments are all styled in a yellow background colour just like a regular patch, except for Phab requests now hidden in favour of the separate section. I’ll make the search results consistent by treating all of them as patches.

Calixte’s query contains resolution=--- but the bug is FIXED, so it’s unrelated. It’s rather Bug 1533610.

My bad...

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #1)

Emma’s search queries include “Attachment is patch: true” but it’s actually not working. For example, Bug 1518058 comes first but it doesn’t have any patch.

This problem is due to the query and basically the bad Custom Search UX. “Attachment is patch: true” doesn’t work but “Attachment is patch: 1” does work! Because… it’s… Perl. Activity Stream components have only 28 bugs with a regular patch, and Emma’s query returns no bugs if corrected.

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #7)

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #1)

Emma’s search queries include “Attachment is patch: true” but it’s actually not working. For example, Bug 1518058 comes first but it doesn’t have any patch.

This problem is due to the query and basically the bad Custom Search UX. “Attachment is patch: true” doesn’t work but “Attachment is patch: 1” does work! Because… it’s… Perl. Activity Stream components have only 28 bugs with a regular patch, and Emma’s query returns no bugs if corrected.

This is also mysql's fault. It has no real boolean type, TRUE and FALSE are just 1 and 0 there

The sql this is running is:

SELECT DISTINCT bug_id FROM attachments WHERE ispatch = 'true' AND isprivate = 0

This looks like another thing that could use some syntactic sugar.

Yeah I’ll fix it. The internal code can convert true to 1 and false to 0.

I'm on it, OPERATOR_FIELD_OVERRIDE

That one.

Er, SPECIAL_PARSING I guess.

Attached file GitHub Pull Request

Doing this in a way that doesn't result in possible SQL injection is a bit tricky, so I'll take it.

Assignee: kohei.yoshino → dylan

Well that’s another bug…

Merged to master.

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: