Managed Users

A managed user is an EarthRanger account that signs in with a username and password instead of an email address, carrying the flag User.is_managed_user. They exist for people who have no email address, and therefore cannot hold an EarthRanger Identity in the common Auth0 database.

A managed user’s account lives in a per-site Auth0 managed database connection, named after the site’s slug. That connection deactivates email and phone as identifiers, so the username is the only way in, and it disables self-service password change — a managed user has no address a reset link could be sent to. Their password is therefore set, and later changed, by a site admin and communicated out of band.

Who does what

Creating a managed user spans three systems, and das only owns the last step:

1. An operator sets feature_flags.require_idp and feature_flags.support_managed_users on the site’s TMS tenant record. das never writes to TMS; it only reads these.

2. TMS Auth0 Integration sees both flags set and provisions the site’s managed database connection, named for the site slug, enabling the applications tagged client_metadata.admits_managed_db_users.

3. A site admin creates managed users in Django admin — either outright on the add-user form, or by marking an account that already exists — which creates each one in that connection and records the resulting Auth0 subject on the ER account.

Step 3 offers no control at all until steps 1 and 2 have happened. das checks both flags with an exact comparison against True — the same predicate the integration uses to decide whether to provision — so neither the add-form choice nor the change-form action is ever offered against a connection that was never created. A submission naming the choice on a site without one is refused too: leaving a field out of a rendered form does not stop it being submitted.

Creating a managed user on the add form

On a site that sets both flags, the add-user form offers Managed user beside the email address. An account gets one or the other: a managed user signs in with their username and the password entered here, and has no address for an invitation or a reset link to reach.

The choice is always explicit. das never infers it from a blank email field, so a typo or a cleared box cannot quietly create an Auth0 account for someone.

Everything that can be refused is refused before Auth0 is called, so a rejected attempt leaves nothing behind to clean up:

Refused	Why
A username that reads as an email address or a phone number	The connection deactivates both as identifiers. Unlike marking, this is caught before the EarthRanger account exists.
Django admin access	See “Managed users cannot administer a site” below. The database constraint refuses it too, but only once the local record is written — by then the Auth0 account exists.
An email address alongside the choice	A managed user has none, so an address entered here would sit on an account that can never receive anything at it. Refused rather than dropped, so nothing an admin typed is silently discarded.
A missing password	It is the only credential the account gets, and there is no address a reset link could be sent to.

The password inputs are shown on these sites because here they are operative — everywhere else on an IdP site they are dropped, since the local password is made unusable on save.

If Auth0 fails after the EarthRanger record is saved, the account stays an ordinary unmarked user and the admin is told so, naming Mark as managed user as the way to finish it. The account itself is never rolled back: the add runs inside a transaction, and raising there would leave no account at all rather than one that can be repaired. The marking is — it runs in a savepoint, so a failure part-way through cannot leave a half-marked row behind the message that says the account is ordinary, and a database error cannot take the add down with it.

Every new account needs a way to sign in

Where an identity provider is in use the local password is not operative, so a new account signs in one of two ways: by following an invitation sent to its email address, or as a managed user. The add form refuses an account offered neither, rather than saving one nobody can sign in as. Where the site has managed users the refusal names both routes; where it does not, it asks for an address.

Two site shapes are exempt:

• Organization-scoped sites (idp_org_id set) provision their accounts out of band, so an address is not the route in and the invitation is suppressed anyway. Applying the rule there would leave an admin with no branch they could satisfy.

• Sites without an identity provider keep their own password field, a third route this rule does not model.

Marking a user as a managed user

The second route, for an account that already exists. On the user’s change form in Django admin, Mark as managed user opens a page that asks for the password, then creates the account in Auth0 and records it locally. The control is disabled, with the reason as its tooltip, when the account cannot be marked; the URL refuses the same cases, so it is not a way around the disabled control.

The change form shows whether an account is already a managed user, read-only — marking is done through the action, not by editing the field — and the user list can be filtered on it.

An account cannot be made a managed user when:

Reason	Why
The site is not set up for managed users	No managed database connection exists to create them in.
It is a system user	Automatically generated accounts are not people.
It has Django admin access	See “Managed users cannot administer a site” below.
It is already a managed user	Use Set password to change their password.
It signs in with an EarthRanger Identity	Contact EarthRanger Support to unlink it first — that unlink is audited and does not live in the site-admin interface.
Its username reads as an email address or a phone number	Auth0 refuses those on a managed database connection, even though EarthRanger accepts them. Rename the user first.

The password is validated by EarthRanger’s own AUTH_PASSWORD_VALIDATORS, which are a stricter set than the Auth0 connection enforces, so a password the form accepts is one Auth0 accepts.

Auth0 is written before the EarthRanger record. A failure therefore leaves an unmarked user rather than a managed user with no account behind it to sign in as.

If the username already exists in the connection, the operation adopts that account: it takes over the existing subject and applies the password just entered, so running the action again repairs a half-completed attempt. It is refused only when another EarthRanger user already holds that subject.

Adoption matters because an Auth0 account that no EarthRanger record points at is not inert. Its owner misses the account-linking gate on sign-in and is sent to the legacy username and password form, which checks the EarthRanger-local password this flow deliberately makes unusable. They dead-end there, with no email address and so no way to recover on their own.

Setting a managed user’s password

Set password on the change form is the only way a managed user’s Auth0 password can change. The sign-in page’s Forgot password has no address to send to, and the connection disables self-service change in any case, so the admin sets it here and passes it on the same way the first one was delivered.

The new password goes to Auth0 and nothing is written locally. A managed user’s EarthRanger password was made unusable when they were marked, and it is not what they sign in against.

The control is offered for managed users on any site, including one whose IdP settings have since been turned off. Both site flags can be cleared after accounts have already been marked, which leaves managed users whose connection no longer exists — in that case the control is shown disabled and says so, rather than disappearing at the moment an admin most needs to know why they cannot act. As with marking, the URL refuses every case the control does.

On those same accounts Email password reset is disabled and explains that there is no address to send a link to, instead of the self-service guidance an account on the common database gets — but only while the site still sets require_idp.

Clearing that flag reverses it. The site is back on EarthRanger’s own authentication, and a managed user’s EarthRanger password is still unusable from when they were marked, so they cannot sign in at all until an operator runs clear_auth0_ids to unlink them. For one who has an email address the ordinary reset is the way back in rather than a dead end, so it is deliberately left in place.

Managed users cannot administer a site

is_managed_user and is_staff/is_superuser are mutually exclusive, enforced by a database constraint (accounts_user_managed_user_is_not_administrative). Managed users are deliberately limited accounts — a username, no email, no self-service recovery — and not the kind of identity that should administer a site. The constraint guards both directions: marking an administrator as a managed user, and promoting an existing managed user to one.

A second constraint (accounts_user_managed_user_requires_auth0_id) requires an auth0_id alongside the flag, because is_managed_user says which Auth0 database a linked account belongs to and means nothing on an account that is not linked at all. The three states are:

auth0_id	is_managed_user
unset	False	Not linked to Auth0.
set	False	Signs in with an EarthRanger Identity, against the common database.
set	True	A managed user, against this site’s managed database.

Related

The site slug that names the connection is published to clients as site_slug on /status, so a sign-in page can name the connection without deriving it from the hostname.