Create a common dev user

[slifty]

Due to our use of FusionAuth we can't reuse the same dev user across instances of our development environment. This is frustrating because it means it's a lot harder to know / remember what to use when testing things locally.

I'd like to propose we create a development user that our devenv provisioning script injects into the database -- this way we can all log in using that account and won't need to manually create a new user every time we re-provision.

[cecilia-donnelly]

That would work! We'd add the user to the FusionAuth Local tenant and ideally the back-end (local) client (though it appears that most local users are not associated with any particular client at the moment - do you remember if that's a problem @jasonaowen ?).

[mithuna]

Yes I agree with this. good idea

[mithuna]

in early 2021 or something We have worked a project to create a user at vagrant start. This was to help with the unit test failing in local issue and the reason to have a dummy account for the delete account to orphan to. But we were not able to figure out how to get a dummy account set up in local by default.. The solutions we came up were not worthy investing engineering time.
https://permanent.atlassian.net/browse/PER-8041

[slifty]

For those without access it seems to have come down to:

• the problem with using the API is the web server might not be available;
• the problem with putting it in a test is the test suite then cannot be run twice (and therefore cannot be run locally);
• the problem with creating it with SQL is that there are many records created during account creation and we'd risk going out of date.

I would offer, though, that if this is treated as a MIGRATION locked into the current moment of time (as opposed to a SQL script that is run after migrations and has to be constantly maintained), that data would be safe as a snapshot of the current footprint. That is: user data is always going to be migrated alongside changes, so this user data would be no different.

What do folks think of that approach -- some kind of conditional migration that only runs in local / dev?

[jasonaowen]

Yep, 8041 is a different instance of this exact problem! Coming up with a way to solve it should also solve this.

@mithuna documented the approach we eventually identified but have not taken the time to implement:

make a PHP script in back-end that we could run during vagrant up and during CI before the tests, which calls the same back-end code that the API controller would

That should not require much in the way of updates, does have the database available, and does not need a web server. We believe such an approach should work because we're doing something similar (but simpler) in the database migration script.

The twist for this problem is setting the subject to the FusionAuth user's ID, which is a UUID. So something like

createUser('Curator', null);
createUser('Shared Dev Account', '3bf07ab2-b865-4ded-af67-bb2aea93c25b');

The other thing that is relevant here is the work I have scheduled for this sprint of allowing account creation in FusionAuth. If things go well and it turns out to be possible to auto-create a Permanent account upon showing up with a token issued by FusionAuth, then this would turn into a non-issue, and we'd just be left with the curator account problem!