Skip to content

fix: treat recovered instances with users as initialized - #5216

Open
BetterAndBetterII wants to merge 1 commit into
Dokploy:canaryfrom
BetterAndBetterII:fix/is-admin-present-org-owner
Open

fix: treat recovered instances with users as initialized#5216
BetterAndBetterII wants to merge 1 commit into
Dokploy:canaryfrom
BetterAndBetterII:fix/is-admin-present-org-owner

Conversation

@BetterAndBetterII

@BetterAndBetterII BetterAndBetterII commented Aug 29, 2026

Copy link
Copy Markdown

Summary

After a partial DB restore, user / organization rows can survive while the member.role = owner row is gone. isAdminPresent() only checked owner membership, so / treated the instance as a fresh install and redirected to Setup.

Changes

  • isAdminPresent() returns true when an owner membership exists, or an organization has a real owner user, or any user exists.
  • Self-hosted first-admin signup uses that same check so a recovered instance cannot create a second first admin.
  • The post-create hook still keys off owner membership only, so a real first install still creates the organization.

Test plan

  • admin-present vitest (4 passed)
  • Recovered instance with users but no owner membership stays off Setup / register
  • Fresh empty install still reaches Setup and creates the first admin + org

Fixes #5192

Greptile Summary

This PR broadens initialized-instance detection so partially restored installations with surviving users cannot re-enter first-admin setup.

  • Treats owner memberships, live organization owners, or any user as evidence of initialization.
  • Reuses the shared initialization check for self-hosted local signup.
  • Preserves owner-membership-only behavior in the post-create organization hook.
  • Adds focused initialization-state tests.

Confidence Score: 4/5

The PR appears safe to merge; the only identified issue is a non-blocking redundant database query in initialization detection.

The changed checks prevent recovered instances from reopening first-admin registration as intended, while the organization-owner lookup adds avoidable work because the following user lookup already covers every successful owner relation.

Files Needing Attention: packages/server/src/services/admin.ts

Reviews (1): Last reviewed commit: "fix: treat recovered instances with user..." | Re-trigger Greptile

Greptile also left 1 inline comment on this PR.

isAdminPresent only checked member.role=owner, so a partial DB restore
that kept user/org rows but lost the owner membership sent / to Setup.
Fall back to organization.owner and any existing user. Self-hosted
first-admin signup uses the same check; the post-create hook still keys
off owner membership so a real first install creates the org.

Fixes Dokploy#5192
@dosubot dosubot Bot added the size:M This PR changes 30-99 lines, ignoring generated files. label Aug 29, 2026
Comment on lines +50 to +58
const org = await db.query.organization.findFirst({
with: {
owner: true,
},
});

if (org?.owner) {
return true;
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Redundant organization owner query

The organization-owner lookup cannot affect the result because every loaded owner is also an existing user covered by the subsequent user lookup. Removing this query avoids unnecessary database work and simplifies the fallback logic.

Suggested change
const org = await db.query.organization.findFirst({
with: {
owner: true,
},
});
if (org?.owner) {
return true;
}

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

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

Labels

size:M This PR changes 30-99 lines, ignoring generated files.

Projects

None yet

1 participant