Every account on this server. The owner is fixed — the database itself refuses to demote or remove it — so that
- row cannot be changed from here.
+ row cannot be changed from here, and no other account can be promoted into it.
+
+
{data.users.map((user) => {
const busy = pendingId === user.id;
@@ -114,7 +124,9 @@ export const UsersSection = () => {
- {data.roles.map((role) => (
+ {/* The owner's row needs its own value present to render at all, and it is disabled
+ anyway. Every other row offers only what the server will accept. */}
+ {(user.isOwner ? data.roles : data.assignableRoles).map((role) => (
{role}
diff --git a/src/databases/officer_db/src/index.ts b/src/databases/officer_db/src/index.ts
index 8c8a9a58..dc5fa039 100644
--- a/src/databases/officer_db/src/index.ts
+++ b/src/databases/officer_db/src/index.ts
@@ -2,6 +2,7 @@ export {
getUsers,
getUserById,
getUserByEmail,
+ getUserByUsername,
getOwnerUser,
getUserCount,
createUser,
diff --git a/src/databases/officer_db/src/queries/auth.ts b/src/databases/officer_db/src/queries/auth.ts
index 79a5dea3..982614f4 100644
--- a/src/databases/officer_db/src/queries/auth.ts
+++ b/src/databases/officer_db/src/queries/auth.ts
@@ -19,6 +19,14 @@ export async function getUserByEmail(email: string): Promise {
+ const [user] = await db.select().from(users).where(eq(users.username, username));
+ return user;
+}
+
// The owner: the one account with role 'Super Admin'. Sidecars that need "who is the owner" (e.g. the
// agent sidecar, which PM2 starts with no email in its env) resolve it here rather than being told by
// the main server.
@@ -27,8 +35,15 @@ export async function getUserByEmail(email: string): Promise {
- const [user] = await db.select().from(users).where(eq(users.role, 'Super Admin')).limit(1);
+ const [user] = await db.select().from(users).where(eq(users.role, 'Super Admin')).orderBy(users.id).limit(1);
return user;
}
diff --git a/src/servers/api/users/create-user.ts b/src/servers/api/users/create-user.ts
new file mode 100644
index 00000000..eb9b4967
--- /dev/null
+++ b/src/servers/api/users/create-user.ts
@@ -0,0 +1,89 @@
+import type { Handler } from 'hono';
+import { createUser, getUserByEmail, getUserByUsername, USER_ROLES } from 'officerdb';
+import type { UserRole } from 'officerdb';
+import argon2 from 'argon2';
+import * as errors from '@@/custom-errors';
+import { provisionUserDirs } from '@@/data-path';
+import { validatePassword } from '../auth/validate-password';
+import { validateUsername } from '../auth/validate-username';
+import { toPublicUser } from './manage-users';
+
+// The owner creating a second account. Until this existed, `createUser` had exactly one call site —
+// `auth/bootstrap.ts`, gated on an empty user table — so every non-owner account on any instance had
+// been inserted into Postgres by hand.
+//
+// ── Why the owner sets the password ──
+//
+// The alternative is an invite: a token emailed to the person, who then sets their own. That is the
+// better shape and it needs a mail path, a token table and an expiry policy. This is the honest
+// intermediate: the owner types a password and tells the person, the same way they would hand over a
+// wifi key. `passwordChangedAt` stays null, so nothing pretends the person chose it.
+//
+// ── Status is 'Active', deliberately ──
+//
+// The column defaults to 'Unverified' and `signin.ts` refuses anything that is not 'Active' with a bare
+// UNAUTHORIZED. So an account created at the default would be indistinguishable from a wrong password,
+// which is precisely the trap the hand-INSERT route fell into. An account the owner created in the admin
+// UI is verified by definition — the owner is the verification.
+
+/** Roles this route may assign. Never 'Super Admin' — see below. */
+const ASSIGNABLE_ROLES = USER_ROLES.filter((r) => r !== 'Super Admin');
+
+export const createUserHandler: Handler = async function (ctx) {
+ const body = (ctx.get('body') ?? {}) as Record;
+
+ const email = typeof body.email === 'string' ? body.email.trim().toLowerCase() : '';
+ const name = typeof body.name === 'string' ? body.name.trim() : '';
+ const password = typeof body.password === 'string' ? body.password : '';
+ const role = typeof body.role === 'string' ? body.role : 'Member';
+
+ if (!email || !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) throw errors.BAD_REQUEST('Invalid email address');
+ if (!name) throw errors.BAD_REQUEST('Name is required');
+
+ // The same validators bootstrap uses. A member's password protects the same surface a member can
+ // reach, so there is no argument for a weaker rule here — and two different rules would mean the
+ // owner could create an account that could not then change its own password to something similar.
+ const username = validateUsername(typeof body.username === 'string' ? body.username : undefined);
+ validatePassword(password);
+
+ // Refused rather than filtered, so the owner is told instead of quietly getting a Member.
+ //
+ // There is exactly one owner. The database only pins user 1's role — a row-level CHECK cannot say
+ // "no OTHER row may hold this" — so a second Super Admin is storable, and `getOwnerUser()` would then
+ // return whichever the query reached first. That answer decides the identity the agent sidecar runs
+ // as, who reaches the vault and which origin is privileged, so it is not a thing to leave to a query
+ // plan. If the owner ever needs to hand the server over, that is a deliberate transfer, not a dropdown.
+ if (!(ASSIGNABLE_ROLES as readonly string[]).includes(role)) {
+ throw errors.BAD_REQUEST(
+ role === 'Super Admin'
+ ? 'There is one server owner and it cannot be created here.'
+ : `Role must be one of: ${ASSIGNABLE_ROLES.join(', ')}`,
+ );
+ }
+
+ // Checked before the insert purely for the message — both columns are unique, so the database is the
+ // real guard and this is a race it can lose harmlessly (the insert then throws).
+ if (await getUserByEmail(email)) throw errors.CONFLICT('An account with that email already exists');
+ if (await getUserByUsername(username)) throw errors.CONFLICT('That username is taken');
+
+ const user = await createUser({
+ email,
+ password: await argon2.hash(password),
+ name,
+ username,
+ status: 'Active',
+ role: role as UserRole,
+ });
+
+ // After the row, and not fatal if it fails. A missing directory is repairable from a shell
+ // (`bun scripts/provision-user-dirs.ts `); an account that half-exists because mkdir failed
+ // is not, and the owner would have to go into Postgres to clean it up — the exact thing this route
+ // is here to stop being necessary.
+ try {
+ provisionUserDirs(email);
+ } catch (ex) {
+ console.warn(`[users] created ${email} but could not provision its data directories`, ex);
+ }
+
+ return ctx.json({ user: toPublicUser(user) }, 201);
+};
diff --git a/src/servers/api/users/manage-users.ts b/src/servers/api/users/manage-users.ts
index 07b57098..9a3f7785 100644
--- a/src/servers/api/users/manage-users.ts
+++ b/src/servers/api/users/manage-users.ts
@@ -21,7 +21,8 @@ type PublicUser = {
isOwner: boolean;
};
-const toPublicUser = (u: Awaited>[number]): PublicUser => ({
+/** Shared with create-user.ts, so a created account and a listed one are described the same way. */
+export const toPublicUser = (u: Awaited>[number]): PublicUser => ({
id: u.id,
email: u.email,
name: u.name,
@@ -37,7 +38,10 @@ export const listUsersHandler: Handler = async function (ctx) {
const users = await getUsers();
return ctx.json({
users: users.sort((a, b) => a.id - b.id).map(toPublicUser),
+ // Every role, so the owner's own row can display its value. The UI must not offer 'Super Admin' in a
+ // picker — both write paths refuse it — which is what `assignableRoles` is for.
roles: USER_ROLES,
+ assignableRoles: USER_ROLES.filter((r) => r !== 'Super Admin'),
ownerId: OWNER_USER_ID,
});
};
@@ -58,6 +62,15 @@ export const updateUserRoleHandler: Handler = async function (ctx) {
throw errors.FORBIDDEN('The server owner cannot be demoted.');
}
+ // And nobody else can be promoted INTO it. The CHECK constraint pins user 1's role but cannot stop a
+ // second row holding it — a row-level check cannot see other rows — and `getOwnerUser()` resolves the
+ // owner by that role, so two holders make "who owns this server" a question the query plan answers.
+ // It decides the agent sidecar's identity, vault access and which origin is privileged. Handing the
+ // server over is a deliberate act, not a dropdown.
+ if (id !== OWNER_USER_ID && role === 'Super Admin') {
+ throw errors.FORBIDDEN('There is one server owner, and this is not how it changes.');
+ }
+
const existing = await getUserById(id);
if (!existing) throw errors.NOT_FOUND('User not found');
diff --git a/src/servers/api/users/users-router.ts b/src/servers/api/users/users-router.ts
index 440beaa2..326ef152 100644
--- a/src/servers/api/users/users-router.ts
+++ b/src/servers/api/users/users-router.ts
@@ -5,6 +5,7 @@ import { isSuperAdmin } from '@@/super-admin';
import * as errors from '@@/custom-errors';
import { updateUserHandler } from './update-user';
import { listUsersHandler, updateUserRoleHandler, deleteUserHandler } from './manage-users';
+import { createUserHandler } from './create-user';
import { capabilityAdminRouter } from './capabilities-routes';
export const usersRouter = createRouter();
@@ -24,6 +25,9 @@ const ownerGate: MiddlewareHandler = async (ctx, next) => {
};
usersRouter.get('/', ownerGate, listUsersHandler);
+// POST, not PUT — and worth noting they sit one line apart. `PUT /` is the selfService exception every
+// account may call on itself; `POST /` creates somebody else and is the owner's alone.
+usersRouter.post('/', ownerGate, createUserHandler);
usersRouter.patch('/:id/role', ownerGate, updateUserRoleHandler);
usersRouter.delete('/:id', ownerGate, deleteUserHandler);
diff --git a/src/servers/data-path.ts b/src/servers/data-path.ts
index 1e605638..e4a0fafb 100644
--- a/src/servers/data-path.ts
+++ b/src/servers/data-path.ts
@@ -42,6 +42,37 @@ export const getHomeDir = (email: string) => join(DATA_PATH, email, 'home');
// terminals/chats/tasks share config and credentials with the shell they use outside Officer.
export const getOwnerHomeDir = (email: string): string => process.env.HOME_DIR ?? getHomeDir(email);
+// The directory skeleton a new account gets under DATA_PATH.
+//
+// Most of these are also created on demand by whichever feature owns them, so pre-creating them buys
+// legibility more than function — the tree shows what an account has without it having to be used first.
+// `home` is the exception and the reason this exists: nothing else creates it, and it is where a
+// non-owner's sessions would run.
+//
+// Single-sourced here rather than in the script that used to own the list, because there are now two
+// callers — `scripts/provision-user-dirs.ts` and the owner's create-account handler — and a skeleton
+// that differs depending on how the account was made is a bug nobody would think to look for.
+export const USER_DIRS = [
+ 'home',
+ 'attachments',
+ 'cache',
+ 'dashboards',
+ 'email_accounts',
+ 'general_chat_sessions',
+ 'logs',
+ 'sidecar',
+] as const;
+
+/**
+ * Create an account's root and its skeleton. Idempotent — an existing directory is left exactly as it is.
+ *
+ * Keyed on email because that is what the on-disk layout uses everywhere else (`DATA_PATH//…`).
+ * Renaming an account's email would orphan its directory; that is pre-existing and not this function's
+ * problem, but it is the reason nothing here derives a path from the id.
+ */
+export const provisionUserDirs = (email: string): void => {
+ for (const dir of USER_DIRS) mkdirSync(join(DATA_PATH, email, dir), { recursive: true });
+};
export const getTmpAttachmentsDir = (email: string) => join(DATA_PATH, email, 'attachments', 'tmp');