[DariuszRozmus]

Context

PR #2427 hides the password-login link when the backend reports:

{
  "local_users_enabled": false
}

The current implementation initializes localUsersEnabled to true. As a result, on a Keycloak-only deployment the password-login link may be visible briefly before the first response from the backend is received.

The purpose of this task is to fix this initial-state problem and make the affected login flow easier to understand without introducing a broader authentication refactor.

Scope

The work should be limited to:

• AuthService;
• LoginPanel;
• the related response type;
• focused tests or manual verification of the affected behavior.

The existing backend API and deployment configuration must remain unchanged.

Planned changes

1. Represent the capability as unknown initially

Change the frontend state from an unconditional boolean:

const [localUsersEnabled, setLocalUsersEnabled] = useState(true);

to a state that can represent the fact that the backend has not responded yet:

const [localUsersEnabled, setLocalUsersEnabled] = useState<boolean | undefined>();

The intended behavior is:

• undefined: the frontend has not received a successful capability response yet;
• true: local users are enabled;
• false: local users are disabled.

After a successful response from GET /:

• use the backend value when local_users_enabled is present;
• treat a missing field as true for compatibility with older backends.

A failed request must not set the value to true. If a previous value was already known, it should remain unchanged until a later successful response.

2. Prevent password login from being offered before confirmation

On PLGrid/Keycloak deployments:

• do not display the password-login link while localUsersEnabled is undefined;
• display it only when localUsersEnabled === true;
• hide it when localUsersEnabled === false;
• do not allow the password form to be selected when local users are disabled.

The backend remains the final authority and must continue to reject disabled local login with HTTP 403.

Non-PLGrid/local deployments should preserve their current behavior.

3. Improve only the local names involved in this flow

Rename the directly affected UI state variables to make their meaning clearer:

• namePasswordLoginSelected → isPasswordLoginSelected;
• namePasswordLogin → showPasswordLoginForm.

Do not perform a broad rename of altAuth, ResponseRoot or all authentication-related terminology in this task. Those can be handled separately if needed.

4. Add focused verification

Add or update tests, if the existing test setup supports them, for:

• PLGrid deployment with local_users_enabled: true;
• PLGrid deployment with local_users_enabled: false;
• the initial state before the backend response;
• a response without local_users_enabled;
• a failed capability request;
• the existing non-PLGrid/local behavior.

If adding component tests would require creating a new test infrastructure, perform a focused manual browser verification instead and document the scenarios checked.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.

[Copilot]

🟢 Approval recommended

The change is a small, correct, and internally consistent UI-visibility fix with the backend remaining authoritative, and no concrete issues were found.

No open issues 🎉

_{Review effort: Balanced}