Please push this small change directly into production when ready. This change should be prioritized ahead of the v1.1 changes. Issue Users of the kickoff form are asking questions within the main project tracker bug; however, no one is cc'ed on that bug. They're only cc'ed in their respective functional area bugs. Change Requested Whenever a sub bug is filed please also cc the primary contact point for that area into the main tracker bug too. This way these individuals will see requests for updates even if the requester posts the comment in the main bug instead of the sub bug. Here is the listing of people: Security: Curtis Koenig (email@example.com) Finance: Michelle Cristobal (firstname.lastname@example.org) & Winnie Aoieong (email@example.com) Legal: Liz (firstname.lastname@example.org) Privacy / Project: Stacy Martin (email@example.com) Privacy / Policy : Alina Hua (firstname.lastname@example.org)
Note to self: To avoid keeping a hard coded mapping of primary contact points for each type of dependent bug, internally we would just look at the default cc setting for the component of the dependent bug and add those to the parent bug after we have created the necessary dependencies.
David - the whole legal team is cced by default on all legal bugs. Am I correct that if you do as you've suggested in comment 1, all legal team members would also be cced on the parent bug? I think they'd find it annoying to start getting bug mail about every parent bug that has a dependent legal bug, even if I delete everyone except the assignee as soon as possible. I guess that could be remedied by setting Zimbra filters appropriately, which I could help them do. Does that sound right?
(In reply to Liz Compton from comment #2) > David - the whole legal team is cced by default on all legal bugs. Am I > correct that if you do as you've suggested in comment 1, all legal team > members would also be cced on the parent bug? I think they'd find it > annoying to start getting bug mail about every parent bug that has a > dependent legal bug, even if I delete everyone except the assignee as soon > as possible. I guess that could be remedied by setting Zimbra filters > appropriately, which I could help them do. Does that sound right? Ok. I will not go that route then. I will need to maintain a mapping of child bugs and their primary contact points as mcoates pointed out in comment 0. Originally I was thinking we could save the pain of editing the code to maintain the mappings by just utilizing Bugzilla's built in cc list feature. So what I will need then is a list of primary contact addresses for each dependent bug and I will put the mapping in the code. So foreach I need one address: Legal: Data Safety: Security: Finance: Privacy Vendor: Privacy Project: Privacy Technical: Thanks dkl
Legal: email@example.com Data Safety: n/a - this should go away per bug 850939 Security: firstname.lastname@example.org, Finance: email@example.com, & firstname.lastname@example.org, Privacy Vendor: email@example.com, Privacy Project: firstname.lastname@example.org, Privacy Technical: email@example.com, Policy/Business Partner: firstname.lastname@example.org (this is a new category per another 1.1 bug) Copying in all the above people into this bug as an FYI they'll be getting more bugmail. All, there are lots of easy ways to filter the main project bugs into a specific folder. Ping me if more info is needed.
Changes pushed to devel instance for testing. Please let me know if it adds the proper people to the main tracker bug: https://bugzilla-dev.allizom.org/form.moz.project.review dkl
Reminder to take a look at these so we can get it pushed live for this week's code update.
I tried submitting the form from the link about three times. Each time the right ccs showed up initially, but there was an error message saying "The parent bug was created successfully, but creation of the dependent bugs failed. The error has been logged and no further action is required at this time." If I tried to go to one of the dependent bugs and then come back to the master bug, the ccs had disappeared.
Ok. I have tracked down what I believe to be the issue and pushed some new code to the test instance for your approval. Committing to: bzr+ssh://email@example.com/bmo/4.2-dev modified extensions/MozProjectReview/Extension.pm Committed revision 8460. Please give it a try and let me know if it works better now. https://bugzilla-dev.allizom.org/form.moz.project.review dkl
(In reply to Liz Compton from comment #9) > I tested it. The right ccs were created, but the legal bug wasn't created. > All other dependent bugs were created and looked right. One of my changes to better align the form with actual Legal component names was not quite there yet so that may have cause Legal bug issue. Please try once more if you have time. Thanks dkl
Same thing happened again.
(In reply to Liz Compton from comment #11) > Same thing happened again. Sigh. Missed one of the other Legal components. [Fri Apr 19 12:48:03 2013] [warn] [Bug 843774] Failed to create additional moz-project-review bugs:\nlegal : There is no component \n named 'Vendor/Services'\n in the 'Legal' product.\n I will doublecheck them all. When we refresh the database for bugzilla-dev.allizom.org, I have to manually recreate the Legal and Finance products/components since the database is sanitized before importing. Meaning all private bugs and products are removed. Please try one more time :) dkl
Sorry, the same thing happened again. No legal bug and an error message.
(In reply to Liz Compton from comment #13) > Sorry, the same thing happened again. No legal bug and an error message. Ugh. This time it was missing the legal permission group (those are also removed as part of the sanitizaton process). I have added the group. dkl
It worked perfectly this time. Yippee!
Thanks. Committing to: bzr+ssh://firstname.lastname@example.org/bmo/4.0 modified extensions/MozProjectReview/Extension.pm Committed revision 8510. dkl