phacility/phabricator · warning · PhutilArgumentUsageException

User account "%s" is not disabled. You can only enable accou

Error message

User account "%s" is not disabled. You can only enable accounts that are disabled.

What it means

Thrown by `bin/people enable --user <username>` when the target account is NOT disabled. Enable exists solely to reverse a disable (it applies PhabricatorUserDisableTransaction with new value false); enabling an active account would be a no-op, so the workflow aborts with a PhutilArgumentUsageException before writing transactions.

Source

Thrown at src/applications/people/management/PhabricatorPeopleManagementEnableWorkflow.php:23

  protected function didConstruct() {
    $arguments = array_merge(
      $this->getUserSelectionArguments(),
      array());

    $this
      ->setName('enable')
      ->setExamples('**enable** --user __username__')
      ->setSynopsis(pht('Enable a disabled user account.'))
      ->setArguments($arguments);
  }

  public function execute(PhutilArgumentParser $args) {
    $user = $this->selectUser($args);
    $display_name = $user->getUsername();

    if (!$user->getIsDisabled()) {
      throw new PhutilArgumentUsageException(
        pht(
          'User account "%s" is not disabled. You can only enable accounts '.
          'that are disabled.',
          $display_name));
    }

    $xactions = array();
    $xactions[] = $user->getApplicationTransactionTemplate()
      ->setTransactionType(PhabricatorUserDisableTransaction::TRANSACTIONTYPE)
      ->setNewValue(false);

    $this->applyTransactions($user, $xactions);

    $this->logOkay(
      pht('DONE'),
      pht('Enabled user account "%s".', $display_name));

    return 0;

View on GitHub (pinned to 5720a38cfe)

Solutions

1. No action needed - the account is already enabled
2. To disable instead, run `./bin/people disable --user <username>`
3. In scripts, check getIsDisabled() (or Conduit user.query) before calling enable and treat this message as a no-op success

Example fix

# before
./bin/people enable --user alice
# after (idempotent script guard)
./bin/people enable --user "$USERNAME" 2>&1 | grep -q 'not disabled' \
  && echo "$USERNAME: already enabled (ok)"

$user = id(new PhabricatorPeopleQuery())
  ->setViewer($viewer)
  ->withUsernames(array($username))
  ->executeOne();
if (!$user || !$user->getIsDisabled()) {
  return; // nothing to enable
}

function needsEnable(PhabricatorUser $user) {
  return (bool)$user->getIsDisabled();
}

When it happens

Trigger: Running `./bin/people enable --user alice` on an active, never-disabled account; re-enabling a user who was already re-enabled by a previous run; scripts that enable whole user lists without checking state.

Common situations: Recovery scripts run twice; operators confusing enable/disable direction; LDAP/SSO onboarding automation that calls enable defensively on every login.

Related errors

• User account "%s" is already approved. You can only approve
• User account "%s" is already an administrator. You can only
• Select a user account to act on with "--user <username>".
• This host already has a registered public key ("%s"). Remove
• This host already has a registered private key ("%s"). Remov

AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21). Data as JSON: /api/errors/187cd779f9904d22. Report an issue: GitHub.