928057 - When custom fields are added, a DBA bug should be created to update metrics permissions

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: Administration, task)

Description

[Sheeri Cabral [:sheeri]]

When new custom fields were added, we'd get e-mails asking to give grants to the metrics user for those fields.

Since custom fields have changed and moved to tables, the grant requests should change too.

Here's a sample e-mail:

The custom field 'cf_status_firefox_esr24' has been added to the BMO database.

Please run the following on bugzilla1.db.scl3.mozilla.com:
  GRANT SELECT ON `bugs`.`cf_status_firefox_esr24` TO 'metrics'@'10.22.70.20_';
  GRANT SELECT (cf_status_firefox_esr24) ON `bugs`.`bugs` TO 'metrics'@'10.22.70.20_';
  GRANT SELECT ON `bugs`.`cf_status_firefox_esr24` TO 'metrics'@'10.22.70.21_';
  GRANT SELECT (cf_status_firefox_esr24) ON `bugs`.`bugs` TO 'metrics'@'10.22.70.21_';

Comment 1

[David Lawrence [:dkl]]

Not sure if we need to make any change here. Even though we migrated tracking flags to their own tables, we still will be adding custom fields in the same fashion in the future for other needs. 

So we still need this email to be sent for new standard custom fields as they get added to the bugs table in the same way. 

On a side note, we do need to make sure that metrics has access to the new tracking flags tables

tracking_flags
tracking_flags_visibility
tracking_flags_values
tracking_flags_bugs

This should be a one time grant as we will just be adding data to those. Can you verify that the metrics user has access to those now?

dkl

Comment 2

[Sheeri Cabral [:sheeri]]

OK, Here's my understanding:

This e-mail will still happen for custom fields
We're using custom fields a lot less now
What used to be in custom fields is now in tracking flags

Do I understand correctly?

I've gone through and updated the metrics user grants to include those tables.

Comment 3

[David Lawrence [:dkl]]

(In reply to Sheeri Cabral [:sheeri] from comment #2)
> OK, Here's my understanding:
> 
> This e-mail will still happen for custom fields
> We're using custom fields a lot less now
> What used to be in custom fields is now in tracking flags

Right. We will still be adding custom fields from time to time, not just not on a 6 week schedule as before.
People will still be requesting special fields from time to time for different workflows, etc.

> Do I understand correctly?
> 
> I've gone through and updated the metrics user grants to include those
> tables.

Thanks

That being said, there is a comment in the current code that sends an email that this should possibly be a bug that is created instead of an email. Would it be better for you and your group if we just created a bug automatically in mozilla.org/Server Operations: Database and you can close it when done? If yes, I will change this bug over to track that enhancement. If no, then feel free to close and we can continue the path we have been on.

dkl

Comment 4

[Sheeri Cabral [:sheeri]]

Yes, that would be AWESOME, to automatically create a bug in server operations:database.

Comment 5

[Sheeri Cabral [:sheeri]]

So here's an e-mail we got today:

The custom field 'cf_user_story' has been added to the BMO database.

Please run the following on bugzilla1.db.scl3.mozilla.com:
  GRANT SELECT ON `bugs`.`cf_user_story` TO 'metrics'@'10.22.70.20_';
  GRANT SELECT (cf_user_story) ON `bugs`.`bugs` TO 'metrics'@'10.22.70.20_';
  GRANT SELECT ON `bugs`.`cf_user_story` TO 'metrics'@'10.22.70.21_';
  GRANT SELECT (cf_user_story) ON `bugs`.`bugs` TO 'metrics'@'10.22.70.21_';


The cf_user_story table does not exist.....so I got errors when trying to grant lines 1 and 3. The other 2 grants worked out fine:

> GRANT SELECT ON `bugs`.`cf_user_story` TO 'metrics'@'10.22.70.20_';
ERROR 1146 (42S02): Table 'bugs.cf_user_story' doesn't exist

>   GRANT SELECT (cf_user_story) ON `bugs`.`bugs` TO 'metrics'@'10.22.70.20_';
Query OK, 0 rows affected (0.00 sec)

>   GRANT SELECT ON `bugs`.`cf_user_story` TO 'metrics'@'10.22.70.21_';
ERROR 1146 (42S02): Table 'bugs.cf_user_story' doesn't exist

>   GRANT SELECT (cf_user_story) ON `bugs`.`bugs` TO 'metrics'@'10.22.70.21_';
Query OK, 0 rows affected (0.00 sec)

Just an FYI in case there's more that needs changing (we'd still love it made into a bug directly, of course).

Comment 6

[David Lawrence [:dkl]]

Attachment: 928057_1.patch

Comment 7

[:glob ✱]

Comment on attachment 823624 [details] [diff] [review]
928057_1.patch

Review of attachment 823624 [details] [diff] [review]:
-----------------------------------------------------------------

r=glob with the following to be fixed on commit

::: extensions/BMO/Extension.pm
@@ +709,2 @@
>      if (Bugzilla->usage_mode == USAGE_MODE_CMDLINE) {
> +        Bugzilla->set_user(Bugzilla::User->new({ name => '[e-mail]' }));

use Bugzilla::User->check() so an error is thrown if nobody can't be found.

@@ +711,5 @@
> +        print "Creating IT permission grant bug for new field '$name'...";
> +    }
> +
> +    my $old_error_mode = Bugzilla->error_mode;
> +    Bugzilla->error_mode(ERROR_MODE_DIE);

for clarity do this just before the eval

@@ +766,5 @@
> +        }
> +    }
> +
> +    undef $@;
> +    Bugzilla->error_mode($old_error_mode);

this needs to happen immediately after the eval

Comment 8

[David Lawrence [:dkl]]

Committing to: bzr+ssh://[e-mail]/bmo/4.2
modified extensions/BMO/Extension.pm
Committed revision 9158.