If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

thunderbird flag permissions seem to apply to components that don't exist

RESOLVED FIXED

Status

()

bugzilla.mozilla.org
General
RESOLVED FIXED
9 years ago
6 years ago

People

(Reporter: timeless, Assigned: justdave)

Tracking

Details

(Reporter)

Description

9 years ago
philor asked me to (fully) MailNews Core to some thunderbird flags. having done that, i noticed that some of them listed Core and some listed Core, Core Graveyard and SeaMonkey for the Networking: * components.

something's wrong :) 

at the very least, Bugzilla should warn if flags are applied to components that don't exist (if this was really because reed/justdave/gerv abused the database while we were at Whistler).

blocking-thunderbird3.0b1:

<select name="inclusion_to_remove" multiple="multiple" size="7">
      <option value="34:0">AUS:__Any__
      </option>
      <option value="1:177">Core:Networking: IMAP
      </option>

      <option value="1:178">Core:Networking: News
      </option>
      <option value="1:179">Core:Networking: POP
      </option>
      <option value="1:180">Core:Networking: SMTP
      </option>
      <option value="50:0">MailNews Core:__Any__
      </option>
...
blocking-thunderbird3:

<select name="inclusion_to_remove" multiple="multiple" size="7">
      <option value="34:0">AUS:__Any__
      </option>
      <option value="49:177">Core Graveyard:Networking: IMAP
      </option>

      <option value="49:178">Core Graveyard:Networking: News
      </option>
      <option value="49:179">Core Graveyard:Networking: POP
      </option>
      <option value="49:180">Core Graveyard:Networking: SMTP
      </option>
      <option value="1:177">Core:Networking: IMAP
      </option>
      <option value="1:178">Core:Networking: News
      </option>
      <option value="1:179">Core:Networking: POP
      </option>

      <option value="1:180">Core:Networking: SMTP
      </option>
      <option value="50:0">MailNews Core:__Any__
      </option>
      <option value="17:0">Mozilla Localizations:__Any__
      </option>
      <option value="25:177">SeaMonkey:Networking: IMAP
      </option>
      <option value="25:178">SeaMonkey:Networking: News
      </option>
      <option value="25:179">SeaMonkey:Networking: POP
      </option>

      <option value="25:180">SeaMonkey:Networking: SMTP
      </option>

wanted-thunderbird3:

<select name="inclusion_to_remove" multiple="multiple" size="7">
      <option value="34:0">AUS:__Any__
      </option>
      <option value="49:177">Core Graveyard:Networking: IMAP
      </option>

      <option value="49:178">Core Graveyard:Networking: News
      </option>
      <option value="49:179">Core Graveyard:Networking: POP
      </option>
      <option value="49:180">Core Graveyard:Networking: SMTP
      </option>
      <option value="1:177">Core:Networking: IMAP
      </option>
      <option value="1:178">Core:Networking: News
      </option>
      <option value="1:179">Core:Networking: POP
      </option>

      <option value="1:180">Core:Networking: SMTP
      </option>
      <option value="50:0">MailNews Core:__Any__
      </option>
      <option value="17:0">Mozilla Localizations:__Any__
      </option>
      <option value="25:177">SeaMonkey:Networking: IMAP
      </option>
      <option value="25:178">SeaMonkey:Networking: News
      </option>
      <option value="25:179">SeaMonkey:Networking: POP
      </option>

      <option value="25:180">SeaMonkey:Networking: SMTP
      </option>
      <option value="23:0">Thunderbird:__Any__
      </option>

Comment 1

9 years ago
One of the mass reorg scripts messed the DB. So this is not a bug in Bugzilla itself as hacking the DB directly is not something we can prevent. Moving to mozilla.org to fix the DB.
Assignee: attach-and-request → nobody
Component: Attachments & Requests → Bugzilla: Other b.m.o Issues
Product: Bugzilla → mozilla.org
QA Contact: default-qa → other-bmo-issues
Version: 3.3 → other
As discussed on IRC, the component IDs are all unique, all we have to do is reset the product IDs to match the parent product of the component ID for all non-zero components.  And the move scripts need to be edited to take care of that in the future.
Assignee: nobody → justdave
Status: UNCONFIRMED → NEW
Ever confirmed: true
I just went through and fixed all these on the back end.  The component exclusions all have the correct products listed now.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Component: Bugzilla: Other b.m.o Issues → General
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.