|
Automatic email notification
It would be helpful to have fogbugz email new/edited bug entries to a group of email recipients. Is this feature being considered in future releases?
Conrad E. Krieg
Friday, July 19, 2002
We created a "New Bugs" account where pre-vetted bugs go so managers can assign them to the correct area and assign the correct priority, etc. The email address for this account can be an alias such as dev@company.com, or dev-mgrs@company.com.
Michael H. Pryor
Friday, July 19, 2002
What about having an email option in the Site page that, when enabled, will send any new or modified bugs' (edited, assigned, resolved, closed, moved, etc) description to an email alias?
Conrad E. Krieg
Friday, July 19, 2002
I'm not sure I see a general purpose use for such a feature. I can see it for a project that only had a few people working on it, but if there are more than 4 people in your FB database, the emails are going to be inundating. Maybe we can work the task into our filter list - i.e. the task is I want to see everything that happened since I last visited FB. I'm just not sure email notification is a proper feature to satisfy that task.
Michael H. Pryor
Friday, July 19, 2002
Or perhaps the task should be that a group of developers want to know immediately and automatically when a bug is submitted and/or updated.
Conrad E. Krieg
Friday, July 19, 2002
Well, you could accomplish this now by making a group account such as "Web Site Dev". The mail list for that would go to web-site-dev@company.com. Everyone would get the message, they could all check fogbugz, and the end user responsible for the bug could assign it to his/her personal FB account.
Can you explain more about the situation that you are trying to address? It might help me to envision what could be done if I knew the usage scenario. Right now I'm not sure how having multiple people notified about every bug change is not just super information overload. It seems to push a lot of useless info to those people, whereas they could easily pull the information they needed from FB when they needed it.
Michael H. Pryor
Friday, July 19, 2002
Currently we have about 300 open bugs. What happens quite often is that someone will add a comment/fix/etc. to a bug entry and the only one that is notified is the person that the bug is assigned to when really many developers and testers need to be aware of this. People could go looking for this info, but this does not happen. I think that fogbugz needs automatic spam (for lack of a better phrase) so that the deveopers and testers are more aware of what is happening inside fogbugz.
Conrad E. Krieg
Friday, July 19, 2002
I think there may be 2 different camps here. I am going to attempt to make some sense out of this. We in our company actually have particular interest in this issue because we want to use this software, but more often than not, need multiple parties involved in bug problem solving.
As I interpret it, scenarios are being suggested where multiple people can keep abreast of progress on a particular bug. The goal would be to do this without creating spam for the entire development staff. This could be possible in situations where an originator of a bug or the developer problem-solving against it wants to include someone else that should be informed of the bug and its latest development. For example, in a client-server environment, a bug could be client (executable) related, but the server side developer needs to be aware of how it will be remedied. This could be because a communication from the client to the server will change. In this, there are 3 parties involved (the originator, client-side developer, server-side developer) and all three should be included in the progress. For this, I would suggest a cc field where someone creating/updating a bug can cc someone else. I imagine that this would also include a "Reply All" function, like e-mail does.
In another situation, a developer, end user or tester is interested in the chain of developments related to a particular bug because it affects their decisions/actions. In this case the individuals who create or work on the bug may not always be aware of this relationship/interest, so they do not cc on each communication, but the interested party can "subscribe" to that bug trail. Therefore, every time there is an update to the bug, the subscribed parties are kept abreast of the latest changes. An example of this would be if in a web situation an end user (business person) finds a bug with the HTML interface, and sends a bug report to the HTML developer. The next time the server side developer logs into FogBUGZ and sees this new bug he/she thinks that changes to fix this problem could potentially involve updating server side scripts. Therefore, this server side developer can opt-in to this bug trail by subscribing to it.
By adding these two features, I think it would fulfill all the potential functionality requirements, and at the same time alleviate the concerns about spamming large groups of uninterested people.
Kunal Bajaj
Wednesday, August 14, 2002
I have implemented this feature on our system using python. If anyone is interested, send me an email and I will provide the python code and instruction on how to set this up.
Conrad E. Krieg
Tuesday, September 17, 2002
 Recent Topics
Fog Creek Home
| 
