Skip to content

DIGITAL-789: Update the "default" users for dev#456

Open
akf wants to merge 2 commits into
developfrom
feature/DIGITAL-789-update-default-users-deploydev
Open

DIGITAL-789: Update the "default" users for dev#456
akf wants to merge 2 commits into
developfrom
feature/DIGITAL-789-update-default-users-deploydev

Conversation

@akf

@akf akf commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

Jira ticket

DIGITAL-789

Purpose

I got tired of not being able to just log in as myself on the dev site without first adding myself. Plus, the default user set includes a lot of people who aren't on the project. So with this update:

  • Users who are not on the project anymore are blocked (except for the @example users who are probably used for testing access scenarios, and who won't be able to log in anyway)
  • All the current "Active" users are added

This affects the dev site every time we deploy to it, and local dev if lando si is used to populate it.

Deployment and testing

The easiest thing would be to go to https://digital-gov-drupal-dev.app.cloud.gov/user/login to test this; you should be able to log in there as you would on prod.

That is, assuming we haven't deployed some other update to dev! If we have, merge develop into this branch, which will kick off another deployment to dev, and when that finishes you can test.

You should see the same gsa.gov users in dev as in prod.

Local Setup

If you want to test locally, you'll need to clear out your database before you can successfully run lando si. You won't be able to use drush to do that, because it requires a secure connection to the database and the local dev db isn't set up that way. (That's a thing to fix another day.) I did this:

% lando mariadb
MariaDB [(none)]> drop database drupal10;
MariaDB [(none)]> exit
% lando si
% lando rebuild

You will also need the GSA_AUTH_KEY environment variable for local dev. I have it in my .lando.local.yml file, so you can get it from me if you need it. I don't think it was automatically picked up from there, though -- or maybe I was impatient. As noted in docs/backend.md:

  • Only .gsa.gov emails can authenticate.
  • You must use the https version of the site, http will not work.
  • You must get the GSA Auth Client Secret value from another developer / lead.

To set the value run the following command then paste in the value when asked. Make sure to respond with 'yes' to rebuilding the environment:

./robo.sh lando:set-env GSA_AUTH_KEY (GSA_AUTH_KEY is not the value, it's the name of the env variable).

QA/Testing instructions

  • You should be able to log in using GSA Auth
  • You should see the same gsa.gov users as in prod.

Checklist for the Developer

  • A link to the JIRA ticket has been included above.
  • No merge conflicts exist with the target branch.
  • Automated tests have passed on this PR.
  • A reviewer has been designated.
  • Deployment and testing steps have been documented above, if applicable.

Checklist for the Peer Reviewers

  • The file changes are relevant to the task objective.
  • Code is readable and includes appropriate commenting.
  • Code standards and best practices are followed.
  • QA/Test steps were successfully completed, if applicable.
  • Applicable logs are free of errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants