Adding two feature toggles for new code paths to store online sessions in the existing offline sessions table. Separate the code which is due to be changed in the next iteration in new classes/providers which used instead of the old one.
Closes#27976
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Signed-off-by: Michal Hajas <mhajas@redhat.com>
Co-authored-by: Michal Hajas <mhajas@redhat.com>
Closes#25676
Signed-off-by: vramik <vramik@redhat.com>
Signed-off-by: Pedro Ruivo <pruivo@redhat.com>
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Co-authored-by: Pedro Ruivo <pruivo@redhat.com>
Co-authored-by: Alexander Schwartz <aschwart@redhat.com>
Closes#26941
Signed-off-by: Michal Hajas <mhajas@redhat.com>
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Co-authored-by: Michal Hajas <mhajas@redhat.com>
Closes#26810
Co-authored-by: Thomas Darimont <thomas.darimont@googlemail.com>
Co-authored-by: Martin Kanis <mkanis@redhat.com>
Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
Signed-off-by: Martin Kanis <mkanis@redhat.com>
This PR introduces a String getTaskName() default method to
the ScheduledTask interface and adjusts call sites to use the
implementation derived task name where possible.
Previously, ScheduledTask names were passed around separately, which
lead to unhelpful debug messages.
We now give ScheduledTask implementations control over their task-name
which allows for more flexible naming.
Enlist call StoreSyncEvent.fire(...) to after transaction to ensure realm is present in database.
Ensure that Realm is already committed before updating sync via UserStorageSyncManager
Align Sync task name generation for cancellation to support SyncFederationTest
Only log a message if sync task was actually canceled.
Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
Closes#26460
Signed-off-by: Václav Muzikář <vmuzikar@redhat.com>
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Co-authored-by: Alexander Schwartz <aschwart@redhat.com>
Closes#22922
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Signed-off-by: Pedro Ruivo <pruivo@redhat.com>
Co-authored-by: Pedro Ruivo <pruivo@redhat.com>
Closes#25077
Signed-off-by: Michal Hajas <mhajas@redhat.com>
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Co-authored-by: Pedro Ruivo <pruivo@redhat.com>
Co-authored-by: Alexander Schwartz <aschwart@redhat.com>
closes#22372
Co-authored-by: Erik Jan de Wit <erikjan.dewit@gmail.com>
Co-authored-by: Pedro Igor <pigor.craveiro@gmail.com>
Co-authored-by: Michal Hajas <mhajas@redhat.com>
The problem is again the wrap(...) function.
In case the user is not found, then null is
returned. This can happen when a federated user
is deleted on the federation side but Keycloak
is not informed about it. In that case, the
session is still present but no UserModel can
be created.
Without this patch the stream contains null
values. Some downstream users can not cope well
with that.
The adjustment of the function getUserSessionsCount(...)
is slightly more expensive in execution, but
returns the correct number.
Closes#22428
Co-authored-by: Martin Krüger <mkrueger@mkru.de>
* Review comments to add a test, update the API description and adjust the map storage.
Closes#19348
Co-authored-by: Alexander Schwartz <aschwart@redhat.com>
