Change from Authenticator to EventListener for member ID generation #54

Merged

luisa merged 2 commits from member-id-event-listener into main

2026-08-07 19:24:13 +00:00

luisa commented

2026-08-07 17:47:47 +00:00

Owner

I propose to change from an Authenticator to an EventListenerProvider for automatic generation of member IDs. The main reasons for this change are:

The member ID is also created when an admin adds the member via the admin console
We do not need to reimplement a modified version of the built-in registration flow
Failed generation of the member ID does not block the registration flow

Besides that, the event listener interfaces are generally simpler to implement and setup is easier. If I understood correctly, Keycloak does not have built-in functionality for welcome-emails anyway, so in a custom solution we might be able to wait for the member ID to be generated before sending any emails. Otherwise, the email could simply prompt the user to log into their account to retrieve their member ID.

I propose to change from an `Authenticator` to an `EventListenerProvider` for automatic generation of member IDs. The main reasons for this change are: - The member ID is also created when an admin adds the member via the admin console - We do not need to reimplement a modified version of the built-in registration flow - Failed generation of the member ID does not block the registration flow Besides that, the event listener interfaces are generally simpler to implement and setup is easier. If I understood correctly, Keycloak does not have built-in functionality for welcome-emails anyway, so in a custom solution we might be able to wait for the member ID to be generated before sending any emails. Otherwise, the email could simply prompt the user to log into their account to retrieve their member ID.

luisa added 1 commit

2026-08-07 17:47:47 +00:00

Change from Authenticator to EventListener for member ID generation 087c88161e

luisa added 1 commit

2026-08-07 18:01:22 +00:00

Remove todo 07f2f60ca4

gingermusketeer approved these changes

2026-08-07 18:09:28 +00:00

gingermusketeer left a comment

I don’t have my computer to test this so I gave only reviewed the code.

I am a bit surprised that the validation logic doesn’t prevent a user being created by either an admin or a self registration. If you have tested this and it works then I think this is a good change so that the IDs are generated for admin create users as well.

I don’t have my computer to test this so I gave only reviewed the code. I am a bit surprised that the validation logic doesn’t prevent a user being created by either an admin or a self registration. If you have tested this and it works then I think this is a good change so that the IDs are generated for admin create users as well.

luisa commented

2026-08-07 18:12:19 +00:00

Author

Owner

@gingermusketeer wrote in #54 (comment):

I am a bit surprised that the validation logic doesn’t prevent a user being created by either an admin or a self registration.

I'm not sure what you mean with that? I have tested creating a user from admin and via registration form and the member ID is generated in both cases. Email verification also works with mailtrap now.

@gingermusketeer wrote in https://forge.hornwitser.no/datakollektivet/systemer/pulls/54#issuecomment-744: > I am a bit surprised that the validation logic doesn’t prevent a user being created by either an admin or a self registration. I'm not sure what you mean with that? I have tested creating a user from admin and via registration form and the member ID is generated in both cases. Email verification also works with mailtrap now.

gingermusketeer commented

2026-08-07 18:27:42 +00:00

Owner

@luisa wrote in #54 (comment):

@gingermusketeer wrote in #54 (comment):

I am a bit surprised that the validation logic doesn’t prevent a user being created by either an admin or a self registration.

I'm not sure what you mean with that? I have tested creating a user from admin and via registration form and the member ID is generated in both cases. Email verification also works with mailtrap now.

When we first tested creating users as admins we had a validation error due to required fields not being editable. I was assuming the same would be the case for the member id field but I see now that it isn’t a required field. No other system needs to know about the id so I don’t think it is an issue leaving it as not required for now. We can investigate alternatives if we end up with missing member IDs or needing to make it a required field.

@luisa wrote in https://forge.hornwitser.no/datakollektivet/systemer/pulls/54#issuecomment-745: > @gingermusketeer wrote in #54 (comment): > > > I am a bit surprised that the validation logic doesn’t prevent a user being created by either an admin or a self registration. > > I'm not sure what you mean with that? I have tested creating a user from admin and via registration form and the member ID is generated in both cases. Email verification also works with mailtrap now. When we first tested creating users as admins we had a validation error due to required fields not being editable. I was assuming the same would be the case for the member id field but I see now that it isn’t a required field. No other system needs to know about the id so I don’t think it is an issue leaving it as not required for now. We can investigate alternatives if we end up with missing member IDs or needing to make it a required field.

👍 1

luisa merged commit ee8b41513e into main

2026-08-07 19:24:13 +00:00

luisa deleted branch member-id-event-listener

2026-08-07 19:24:13 +00:00

luisa referenced this pull request from a commit

2026-08-07 19:24:15 +00:00

Merge pull request 'Change from Authenticator to EventListener for member ID generation' (#54) from member-id-event-listener into main