Environment tokens should be able to be managed from the nil environment

[ezekg]

This would remove the requirement that all environments must have an admin, which results in a confusing DX because those admins must be unique i.e. you end up with admins like [email protected] and [email protected], and that gets hard to remember when switching environments. This would also let us implement environments in the current UI.

Instead, you could create an isolated environment using an admin token, and then generate an environment token for it after creation, and then immediately utilize the new environment; vs the current behavior of creating the environment with an admin, logging in as the new environment's admin, then using the new admin's token to generate an environment token, and then finally using the new environment token to utilize the environment.

The simpler approach above is currently how shared environments work (since a global admin is allowed to manage it), but isolated environments are convoluted right now and I think it could be simplified.

[ezekg]

Requiring an admin per-environment also pushes accounts towards their admin limit unnecessarily, since an isolated environment's admins may overlap with admins in the nil environment.

[ezekg]

Alternative here would be to update the uniqueness constraint on users to include the environment. We can reuse existing emails and get rid of this weird bit where admins can't match across environments. One gotcha would be that when working in a shared environment, we'd have conflicting users if that user also existed in the global environment (conflicting on email).

However, we could make it so that isolated environments can have "conflicts", but shared environments can't, to avoid that situation. Or we could just prefer the environment-scoped user upon conflict.

keygen-api/app/models/user.rb

Lines 128 to 129 in 3032144

	validates :email, email: true, presence: true, length: { maximum: 255 }, uniqueness: { case_sensitive: false, scope: :account_id }

UX-wise, this would look like prompting the current admin for their password when creating or switching to an isolated environment, and then using that to generate an environment-scoped admin token.

[ezekg]

I still think the overall best choice would be to allow admins to manage any environment and not just isolated environments. But we also have situations where duplicate users across environments makes sense — e.g. a dev testing in both staging and qa. I feel like a blend of both of these approaches may make the most sense?