Skip to content

Emit explicit DISABLE/ENABLE events on user enabled-flag transitions (#48855) - #48856

Closed
thomasdarimont wants to merge 1 commit into
keycloak:mainfrom
thomasdarimont:issue/gh-48855-user-enabled-disabled-events
Closed

Emit explicit DISABLE/ENABLE events on user enabled-flag transitions (#48855)#48856
thomasdarimont wants to merge 1 commit into
keycloak:mainfrom
thomasdarimont:issue/gh-48855-user-enabled-disabled-events

Conversation

@thomasdarimont

Copy link
Copy Markdown
Contributor

Adds OperationType.DISABLE/ENABLE and EventType.USER_DISABLED/USER_ENABLED so listeners can detect user enable/disable transitions without diffing the JSON representation of a generic UPDATE event.

UserResource.updateUser now emits an additional cloned AdminEvent (DISABLE or ENABLE) alongside the existing UPDATE on actual transitions only. The new user EventType entries are reserved for system-driven flips (workflow steps, custom SPI code) that have no admin context.

Existing USER_DISABLED_BY_*_LOCKOUT events and the UPDATE emission are unchanged for backward compatibility.

Fixes #48855

Co-Authored-By: Claude Opus 4.7 (1M context)

(keycloak#48855)

Adds OperationType.DISABLE/ENABLE and EventType.USER_DISABLED/USER_ENABLED
so listeners can detect user enable/disable transitions without diffing the
JSON representation of a generic UPDATE event.

UserResource.updateUser now emits an additional cloned AdminEvent (DISABLE
or ENABLE) alongside the existing UPDATE on actual transitions only. The
new user EventType entries are reserved for system-driven flips (workflow
steps, custom SPI code) that have no admin context.

Existing USER_DISABLED_BY_*_LOCKOUT events and the UPDATE emission are
unchanged for backward compatibility.

Fixes keycloak#48855

Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
@thomasdarimont
thomasdarimont requested a review from a team as a code owner May 9, 2026 14:16
@thomasdarimont

Copy link
Copy Markdown
Contributor Author

The failing tests are caused by emitted AdminEvents with (ResourceType=User,OperationType=Disable) when a user is explicitly disabled during the tests and updateUser(...) is called.

@thomasdarimont

Copy link
Copy Markdown
Contributor Author

Perhaps the better strategy is to introduce two new user admin API endpoints to explicitly enable/disable a user.
This would not interfere with existing implementations.

@thomasdarimont

Copy link
Copy Markdown
Contributor Author

I'll add another PR later.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add explicit user enable/disable events for AdminEvent and user EventType

1 participant