1149675 - Emails are not sent to default assignee on bug creation

Status: VERIFIED WORKSFORME

(Bugzilla :: Email Notifications, defect)

Description

[jharmon]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150320202338

Steps to reproduce:

Make sure a default assignee is setup for a component that you select.
Make sure you have the email preferences set to receive an email on bug creation.
Create a new bug and have it go into the unconfirmed state.


Actual results:

I can see when the bug is created that it says the email is sent to no one and that it excludes the assignee.  Email is working with any later state changes.  Just not on initial bug creation.   


Expected results:

It should be sending an email to the default assignee, not excluding that person from the email.

Comment 1

[Frédéric Buclin]

Are you really using Bugzilla 4.4.1? If yes, the first step is to upgrade to 4.4.8. Then by default, emails are not sent when the bug is unconfirmed. A screenshot of the email prefs panel would probably help.

Comment 2

[jharmon]

(In reply to Frédéric Buclin from comment #1)
> Are you really using Bugzilla 4.4.1? If yes, the first step is to upgrade to
> 4.4.8. Then by default, emails are not sent when the bug is unconfirmed. A
> screenshot of the email prefs panel would probably help.

Yes I am really on 4.4.1.  I don't want the default to be that they are not sent when unconfirmed. When a new bug is created it as a default assignee.  That default assignee should receive an email when the bug is created if the "A new bug is created" notification is checked. I'll attach a screenshot of the preferences.

Comment 3

[jharmon]

Attachment: picture of email preferences

Comment 4

[Andre Klapper]

(In reply to jharmon from comment #3)
> Created attachment 8586284 [details]
> picture of email preferences

Are these the preferences of the default assignee account (you're logged in with that one)?
Do you have any customizations in your codebase or is that an entirely clean installation?

Also, please upgrade to a version that is not insecure (like 4.4.8).

Comment 5

[jharmon]

(In reply to Andre Klapper from comment #4)

> Are these the preferences of the default assignee account (you're logged in
> with that one)?

The default assignee in this instance is me.  I have tested with another default assignee and it is the same issue.

> Do you have any customizations in your codebase or is that an entirely clean
> installation?

Clean installation other than modifying a few templates and adding some custom fields.

> Also, please upgrade to a version that is not insecure (like 4.4.8).

We are planning on upgrading.  Right now you are so close to 5.0 that we have been waiting for that rather than going to 4.4.8

Comment 6

[jharmon]

Upgraded to 4.4.8 and it is still having the same issue.  It sets the default assignee on bug creation but it does not email the default assignee.  If fact it says emailing no one.

Comment 7

[jharmon]

(In reply to jharmon from comment #6)
> Upgraded to 4.4.8 and it is still having the same issue.  It sets the
> default assignee on bug creation but it does not email the default assignee.
> If fact it says emailing no one.

Sorry, it actually is working now.  I made an error on my side.

Comment 8

[jharmon]

Working now

Comment 9

[Andre Klapper]

It would be great for anybody else facing the same problem if you explained what the error on your side was.

Comment 10

[jharmon]

(In reply to Andre Klapper from comment #9)
> It would be great for anybody else facing the same problem if you explained
> what the error on your side was.

The error was simply the server I was using for the final validation testing. This wasn't working on 4.4.1 and is now working on 4.4.8 so I believe that the upgrade resolved the issue. When I reported the problem I was doing all of my testing against our production implementation because that is where the problem was being reported. I had already changed all of the email settings on the production server so I know it wasn't working there. The error that I describe in Comment 7 was that after the upgrade I did my initial testing on our staging server rather than on our production server.  On the staging server I had not yet changed the email preferences overriding the sending of email when it was being sent by myself. I had already changed that on production when I was reporting this issue on both accounts I was using for the test. Hope this helps.