Closed
Bug 841633
Opened 12 years ago
Closed 12 years ago
Project Kickoff Form: CC sub-bug owners into main project tracker bug
Categories
(bugzilla.mozilla.org Graveyard :: Extensions: MozProjectReview, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mcoates, Assigned: dkl)
Details
(Whiteboard: [v1.0])
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 (curtisk@mozilla.com)
Finance: Michelle Cristobal (mcristobal@mozilla.com) & Winnie Aoieong (waoieong@mozilla.com)
Legal: Liz (liz@mozilla.com)
Privacy / Project: Stacy Martin (smartin@mozilla.com)
Privacy / Policy : Alina Hua (ahua@mozilla.com)
Assignee | ||
Comment 1•12 years ago
|
||
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.
Comment 2•12 years ago
|
||
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?
Assignee | ||
Comment 3•12 years ago
|
||
(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
Assignee: nobody → dkl
Status: NEW → ASSIGNED
Assignee | ||
Updated•12 years ago
|
Flags: needinfo?
Reporter | ||
Comment 4•12 years ago
|
||
Legal: liz@mozilla.com
Data Safety: n/a - this should go away per bug 850939
Security: curtisk@mozilla.com,
Finance: waoieong@mozilla.com, & mcristobal@mozilla.com,
Privacy Vendor: smartin@mozilla.com,
Privacy Project: ahua@mozilla.com,
Privacy Technical: ahua@mozilla.com,
Policy/Business Partner: smartin@mozilla.com (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.
Flags: needinfo?
Assignee | ||
Comment 5•12 years ago
|
||
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
Flags: needinfo?(mcoates)
Assignee | ||
Comment 6•12 years ago
|
||
Reminder to take a look at these so we can get it pushed live for this week's code update.
Comment 7•12 years ago
|
||
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.
Assignee | ||
Comment 8•12 years ago
|
||
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://dlawrence%40mozilla.com@bzr.mozilla.org/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
Flags: needinfo?(liz)
Comment 9•12 years ago
|
||
I tested it. The right ccs were created, but the legal bug wasn't created. All other dependent bugs were created and looked right.
Stacy - One thing I noticed, if I select Separate Party - Yes and Data Access - Yes, which has the description: "Will the other party have access to Mozilla (customer, contributor, user, employee) data?" and is a required field, a privacy vendor bug isn't created. Only if I also answer Yes to Privacy Policy, with the description "Will the vendor have access to Mozilla (customer, contributor, user, employee) data?" in the "Privacy (Policy/Vendor)" section, which is not a required field, is a privacy vendor bug opened. This doesn't seem to me like the right result. Maybe it's already in the v 1.1 changes, but I'd think the question could be removed from the "Privacy (Policy/Vendor)" section as redundant and have a privacy vendor bug opened if the answer is yes to the Data Access question. What do you think?
Flags: needinfo?(liz)
Assignee | ||
Comment 10•12 years ago
|
||
(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
Comment 11•12 years ago
|
||
Same thing happened again.
Assignee | ||
Comment 12•12 years ago
|
||
(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
Comment 13•12 years ago
|
||
Sorry, the same thing happened again. No legal bug and an error message.
Assignee | ||
Comment 14•12 years ago
|
||
(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
Comment 15•12 years ago
|
||
It worked perfectly this time. Yippee!
Assignee | ||
Comment 16•12 years ago
|
||
Thanks.
Committing to: bzr+ssh://dlawrence%40mozilla.com@bzr.mozilla.org/bmo/4.0
modified extensions/MozProjectReview/Extension.pm
Committed revision 8510.
dkl
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: needinfo?(mcoates)
Resolution: --- → FIXED
Updated•6 years ago
|
Product: bugzilla.mozilla.org → bugzilla.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•