feat(user): add EformUser.IsActive so a login can be disabled (#971)

[renemadsen]

Closes #971. Step 1 of 4 — design: microting/eform-angular-frontend#8072, spec: microting/eform-angular-frontend#8073.

One property on EformUser:

public bool IsActive { get; set; } = true;

Why

There is no account-state flag today. LockoutEnabled/LockoutEnd exist but are purely the automatic brute-force delay — nothing in the platform sets them administratively — so a known-good credential cannot be refused for policy reasons. Measured on one production tenant: all four resigned workers still hold a working login, one of them seven weeks after resigning.

The = true is load-bearing

The mapping (step 2) declares HasDefaultValue(true), which makes true this property's sentinel; EF Core omits a sentinel-valued column from the INSERT so the store default applies. Without the initializer a freshly constructed EformUser holds false, EF Core writes that explicitly, and every new account would be created disabled.

Verified empirically against EF Core 10.0.12 (the version pinned in this repo) rather than from memory — an earlier draft of the comment had the direction backwards.

This trap is already sprung elsewhere: ExternalLoginEnabled is a shadow bool with HasDefaultValue(true), and a shadow property cannot have an initializer — so every user created since 20250904105541_AddOAuthLoginSupport has it set to 0 despite the declared default. Dormant only because the property is dead code.

No tests in this PR

Nothing reads the flag yet, so there is no behaviour to assert; this repo has no test project either. The test obligation lands with the login-refusal change that consumes it.

For whoever picks up step 2

• Microting.EformAngularFrontendBase.csproj:14 still pins BasePn 10.0.30 — bump it to this release or dotnet ef migrations add will not see IsActive and will scaffold nothing.
• Copy the precedent at 20250904105541_AddOAuthLoginSupport.cs:41-46: AddColumn<bool>(name: "IsActive", table: "Users", type: "tinyint(1)", nullable: false, defaultValue: true). A naively scaffolded defaultValue: false would disable every existing account on migrate.
• The release that picks this package up must also carry that migration: IdentityDbContext maps the property by convention, and the host materialises whole EformUser rows during boot (Startup.cs:502, Program.cs:263), so a package bump without the column stops the host from starting.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

The documentation claims inactive users cannot sign in, but this package does not enforce that behavior yet.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Adds EformUser.IsActive with an enabled-by-default initializer for future login disabling.

Changes:

• Adds the account activity flag and explanatory documentation.
• Preserves enabled defaults for newly created users.

File summaries

File	Description
eFormApi.BasePn/Infrastructure/Database/Entities/EformUser.cs	Adds IsActive to EformUser.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.