Kim 164906617 super user migrations

[kimallen]

Description

Adds a column is_superuser to the users table.
Adds all current Truss engineers as superusers (except two who have not been added yet as office_users).

Reviewer Notes

The user is created in middleware when the officeuser is created (not in migrations), so running prod migrations does not show user data, so this is difficult to verify.

When I ran the local migration, it seemed to pass, but it is not setting is_superuser to true for me locally, although it did for @mikena-truss when she tried it out. Please uncomment the query in the local migration and see if the is_superuser value gets applied locally.

Setup

To check locally, uncomment the query in the local_migration file.
If you already have your local db set up, run make db_dev_migrate. Then check your db to find 1) a new is_superuser column. 2) SELECT * FROM users WHERE login_gov_email = 'officeuser1@example.com'; and see is_superuser set to true

Code Review Verification Steps

• Secure migrations have been tested using bin/run-prod-migrations - Note: does not show users table data because it's created in middleware instead of migrations.
• Request review from a member of a different team.
• Have the Pivotal acceptance criteria been met for this change?

References

• Pivotal story for this change

[codecov]

Codecov Report

Merging #1940 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1940      +/-   ##
==========================================
+ Coverage   60.51%   60.51%   +0.01%     
==========================================
  Files         193      193              
  Lines       12245    12247       +2     
==========================================
+ Hits         7409     7411       +2     
  Misses       3968     3968              
  Partials      868      868

[lynzt]

Looks good to @garrettqmartin8 and me... 🚢

Sidenote: officeuser1 isn't created till we load data via e2e_basic.go which is run after the migration files are run. Therefore, that user isn't in the db at the time the migration runs. Mikena probably ran the migration but didn't drop the existing data so her field was updated as expected...

[kimallen]

Aaah! Thank you @lynzt - that makes sense- I thought it was something like that. . .