Closed Bug 810114 Opened 8 years ago Closed 7 years ago
Create "Toolkit :: Phishing Protection"
We currently have Firefox :: Phishing Protection. Which has become a bit of an oddity, because the vast majority of the code implementing it now lives in Toolkit. Looking through closed bugs in this component, by far most seem to have involved the backend code. Of the open bugs, that seems to hold as well although not by as large a margin. So, I'd propose that we want a dedicated Toolkit component (:: Safe Browsing) for the backend pieces. And we should either get rid of the existing Firefox component (ie, move everything to Toolkit:SB or Firefox::Security / Firefox::General) or rename it to Firefox :: Safe Browsing for consistency. [The descriptions of both could use a refresh, as well.] I'm on the fence, but I think I slightly prefer keeping a Firefox component for the UI pieces. Thoughts / objects from gcp or gavin? Hmm, and now I see that back in bug 345540 Jesse had the Firefox component renamed from "Safe Browsing" to "Anti-Phishing". So maybe we want a better name. :/
I don't have a strong opinion. Certainly makes sense to have a toolkit component. I think we should keep the "Phishing Protection" name for whatever components we end up with. The front-end pieces of code seem small enough that we could lump them into security/general as you suggest. Otherwise, I have a preference for whatever results in the least amount of bug moving :)
It makes sense to me that (the backends parts of) this are pulled out of "Firefox", as several other projects are using identical code. Frontends parts could go in the current component or something UI or security related. The backend code we have is very "Google SafeBrowsing" specific, so I don't think there's a problem with the name.
Just as a note, once this is decided please post a comment stating what the exact changes are that need to be made to the current product/component sets and we will do it right away. Thanks dkl
In bug 345540, I asked for the change from "Safe Browsing" because the name was confusing bug filers.
Ok, let's go with "Toolkit :: Phishing Protection" and remove "Firefox :: Phishing Protection" A wholesale move of all the existing Firefox::PP bugs to Toolkit::PP sounds simplest. I can take a stab at moving the open bugs that look like front-end to Firefox::mumble, but it's probably not very important.
Ok. Created Toolkit::Phishing Protection. Will need to 1) make sure the same flags are available on the new component as the old and 2) pass this bug over to IT to have them run the proper migration scripts to move the old bugs. glob, are you able to finish this up or I can get to it sunday night after the break? dkl
(In reply to David Lawrence [:dkl] from comment #6) > glob, are you able to finish this up or I can get to it sunday night after > the break? sorry, but i'll have to pick your brains about the easiest way to determine which flags are visible to a component; all i can see are flag or bug centric views, and checking on a flag-by-flag basis would be rather time consuming.
Ohai! I just finished triaging all the open bugs in the (old) Firefox :: Phishing Protection. Can you go ahead with the bulk move of all FF::PP bugs to Toolkit::PP? Or are there still flag issues (comment 7)?
Summary: Create "Toolkit :: Safe Browsing" → Create "Toolkit :: Phishing Protection"
(In reply to Byron Jones ‹:glob› from comment #7) > sorry, but i'll have to pick your brains about the easiest way to determine > which flags are visible to a component; all i can see are flag or bug > centric views, and checking on a flag-by-flag basis would be rather time > consuming. We obviously need to be better at scripting this, but a quick/dirty way to do this is to go to the enter_bug.cgi page for each product, select each of the respective components, look at the attachments drop down and the set bug flags drop down and make sure the same flags are visible for each component. Then make adjustments as necessary in the flags admin UI. dkl
(In reply to David Lawrence [:dkl] from comment #9) > (In reply to Byron Jones ‹:glob› from comment #7) > > sorry, but i'll have to pick your brains about the easiest way to determine > > which flags are visible to a component; all i can see are flag or bug > > centric views, and checking on a flag-by-flag basis would be rather time > > consuming. > > We obviously need to be better at scripting this, but a quick/dirty way to > do this is to go to the enter_bug.cgi page for each product, select each of > the respective components, look at the attachments drop down and the set bug > flags drop down and make sure the same flags are visible for each component. > Then make adjustments as necessary in the flags admin UI. Ugh, something I just realized is that this method does not take into account flags that have been set to disabled in the past that have some set value. Disabled flags are not visible from the enter_bug.cgi page but are visible from show_bug.cgi if the bug has one or more of them set to +/-/? still. So we still may need to do the script approach to capture all flags. Question is, do we really care to migrate flags that are disabled anyway? Would anyone miss the set flags that are disabled? If not, then we could just let them drop when they move. dkl
Are there actually differing flags? I'd have thought they would be the same, or at worst have easy mappings.
(In reply to Justin Dolske [:Dolske] from comment #11) > Are there actually differing flags? I'd have thought they would be the same, > or at worst have easy mappings. Not really. Different flags can have similar names but be enabled for different product/component combinations. When moving a bug from one product to another that has one or more flags "set", it will look for a flag enabled for the new product with the same name and if it finds one, it will migrate the id internally to the new flag (if they are different ids internally). If the flag does not exist at all on the new product, the flag is removed. So the key is to make sure in advance that there is a flag on the new product enabled for the old one to be moved to before moving. In this case, there are flags associated with the bugs that have been disabled in the past but still display on the bug reports if the flag has a "set" value. If the user were to clear the flag for whatever reason, the flag choice would then no longer appear. But do we care if those disabled flags are dropped when moved over or not and only worry about retaining any flag values for flags that are currently active? dkl
I think I have managed now to enable all of the needed flags in the Toolkit product for this move. Moving to IT as they will need to perform the scripts needed to move the components on the production servers. 1. # cd /path/to/bugzilla/root 2. # perl ./contrib/reorg-tools/syncmsandversions.pl Firefox Toolkit 3. # perl ./contrib/reorg-tools/movebugs.pl "Firefox" "Phishing Protection" \ "Toolkit" "Phishing Protection" Then move this bug back here so we can delete the old component. Thanks
Assignee: nobody → server-ops-devservices
Component: Administration → Server Operations: Developer Services
Product: bugzilla.mozilla.org → mozilla.org
QA Contact: shyam
Version: Production → other
Got this error : [email@example.com bugzilla.mozilla.org]$ sudo ./contrib/reorg-tools/movebugs.pl "Firefox" "Phishing Protection" "Toolkit" "Phishing Protection" 'Toolkit'::'Phishing Protection' is missing the following flag(s): review (attachment) review (attachment)
Assignee: shyam → nobody
Component: Server Operations: Developer Services → Administration
Product: mozilla.org → bugzilla.mozilla.org
QA Contact: shyam
Whatever happened here?
Ok. Found the missing flag and enabled for Toolkit :: Phishing Protection. Kicking back to WebOps for another try. Admin, please follow same instructions from comment 13. Thanks dkl
Assignee: nobody → server-ops-webops
Component: Administration → WebOps: Bugzilla
Product: bugzilla.mozilla.org → Infrastructure & Operations
QA Contact: nmaul
Hit another error that dkl fixed, and re-ran to great success: bugzillaadm.private.scl3# time perl ./contrib/reorg-tools/syncmsandversions.pl Firefox Toolkit real 0m0.472s user 0m0.406s sys 0m0.043s bugzillaadm.private.scl3# time perl ./contrib/reorg-tools/movebugs.pl "Firefox" "Phishing Protection" "Toolkit" "Phishing Protection" About to move 755 bugs From 'Firefox' : 'Phishing Protection' To 'Toolkit' : 'Phishing Protection' Press <Ctrl-C> to stop or <Enter> to continue... Moving 755 bugs from Firefox:Phishing Protection to Toolkit:Phishing Protection Touching user profile data for 755 bugs. Updated 4514 users. real 0m16.508s user 0m2.066s sys 0m0.764s
Assignee: server-ops-webops → klibby
Component: WebOps: Bugzilla → Administration
Product: Infrastructure & Operations → bugzilla.mozilla.org
QA Contact: nmaul
Firefox :: Phishing Protection component removed. Closing.
Assignee: nobody → dkl
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.