Bugzilla email headers

[Arthmoor]

Is it possible to have bugzilla alter the email headers it sends out to mark which product it's emailing you a report on? I've just realized that the BOSS section is dropping its emails into the same folder I filter USKP reports into and there's no easy means of refining the filters to separate these.

[AndalayBay]

I'll ask Xae to have a look.

[Guest]

By default, Bugzilla sends all that information in the form of X-Bugzilla headers:

X-Bugzilla-Reason: AssignedTo Reporter
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Test
X-Bugzilla-Component: Heiras
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: naregdrm@gmail.com
X-Bugzilla-Status: CONFIRMED
X-Bugzilla-Priority: Normal
X-Bugzilla-Assigned-To: naregdrm@gmail.com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: priority bug_group bug_id assigned_to short_desc
bug_severity classification op_sys reporter bug_file_loc rep_platform
bug_status version deadline component product

If your email client does not allow you to filter messages by these headers, I can modify them, or modify the subject line to include the product name. Let me know what would work best.

[Arthmoor]

Ah. I wasn't aware it had those headers. I don't usually check those. Thunderbird allowed me to set a custom header filter for it so it's all good.

[Arthmoor]

People are still able to mark new bugs as confirmed when they're not admins. Nothing coming from a regular user should be able to be set that way.

Otherwise you get this: http://bugzilla.dark..._bug.cgi?id=800 (Spoilers if you haven't played yet)

The described scenario is definitely not confirmed, nor am I able to reproduce it, so it shouldn't be marked as such. Bugzilla doesn't allow downgrading a bug from "confirmed" to "unconfirmed" either.

Edited August 9, 2012 by Arthmoor

[AndalayBay]

It's a known issue and one we don't like either. I just found this proposed solution:

Hack the bug filing template to make UNCONFIRMED the default in the

dropdown.

That might be what we need to do, because other than that, I've only seen the Bugzilla devs deny that it's even an issue, which is ridiculous in my opinion.

I did find this: https://wiki.mozilla...IRMED_status.3F

Perhaps we can try that first. Never mind. We had that set already.

Edited August 9, 2012 by AndalayBay

[Arthmoor]

Typical Mozilla. "You have a bug" -> "Nuh uh, no such issue exists!"

I was about to try the vote thing when I realized they've taken out bug voting. Most likely because people were using it as intended, to auto-confirm bugs in Firefox they claim don't exist. So again, in typical Mozilla fashion, they took the "annoying feature" out instead of fixing the actual bugs.

Almost makes me wish we had the IPB tracker at this point, and reminds me why we stopped using Bugzilla on Alsherok back in the day. Hell, I even had half of a bug tracker written for QSFP at one point, then somewhere along the way got distracted, forgot about it, and eventually lost the file to the ages.

[AndalayBay]

I've been thinking about the IPB tracker too. Or purchasing IP.Content and using that as a tracker.

I'll have a look at the database and see if I can switch the status in the DB. We can continue to migrate bugs over and if we can't fix this, then we'll see about porting it to something else. If we do look at porting it, I'll write a migration script so that it can be done at a database level.

[AndalayBay]

I've been looking at the code, and as near as I can tell, it should be setting the default status to unconfirmed. Do you know CGI, Arthmoor?

[Arthmoor]

Would it not be more correct to ask if I know Perl, or whatever language they're using?

I don't, but I've usually been pretty good at figuring out the intent of a piece of code. If it's actually doing as expected then somewhere in this mess people have the ability to change the status upon submission.

[AndalayBay]

Yeah, tells you how much I know about Perl. I skipped that and went straight to PHP 5, I'm afraid.

I've confirmed that when you enter a new bug, it defaults to confirmed. You have to display the advanced options and manually switch it to unconfirmed. Which nobody is going to do - it's ridiculous.

Here's the script:

I'm not sure what that default template is. We've gone in and enabled unconfirmed for every product.

[Arthmoor]

I found the section of code that deals with the unconfirmed status, but it reads as though it's getting the information from the user groups. Could you enable access in bugzilla so I can see the group settings?

There's also some sort of template this eventually dumps to but I doubt that would help with this.

[Guest]

Bugzilla operates with a backbone script that then feeds to the template, which is what you use to customise the installation. Having unconfirmed be the default sounds like a good modification to me, I'll grab the files and see what I can make of it.

edit: Apparently, removing editbugs permissions from general users solved this issue.