Why is the return type Integer rather than int? If it is because of the jackson bug, can it be int now the the PR includes jackson upgrade?

It was not due to jackson bug, the Integer came from assumption that we'd store Enums numeric representations on entity level. In that case we'd want to have possibility to store nulls due to tree store and store hierarchy.

But now, since it has been decided we let each store handle it separately it seems it might make sense to have int there. I'll update it.

I think this method doesn't work with CHM and Hotrod because the MapAdminEventEntity interface has the get/setResourceType methods in String form. When I tested the events I noticed that the type passed to the mcb in this method must match the type found in the entity's interface (CHM uses comparators that simply don't match if the types are different) and I believe this particular case is not being tested properly at the moment. In other words, the AdminEventStoreProviderTest has no tests with searches that involve the resource type.

If you change the OperationType into String in the entity's interface, you will see that the same test fails with CHM because the CHM won't be able to retrieve the events when searching by operation type.

So in this case we either use the enum type in the entity's interface, or change the above to use Arrays.stream(resourceTypes).map(Enum::toString)

Thanks for pointing this out. I agree it is not very well tested. I believe we cannot use enum type in the entity interface due to custom event types (KEYCLOAK-9573). We have to be able to store exact string of the custom type (test AdminEventsStoreProviderTest.handleCustomResourceTypeEvents). Unless we'd store the value somewhere else (e.g. we can add attributes and put it there).

But with custom types querying starts to be a little bit tricky. In scenario when there is more than one custom resource type and admin events are queried by ResourceType.CUSTOM, all custom events are returned regardless of its actual value. Is this expected behavior?

If not we'd need to make additional changes anyway.

If so (and we don't want to store custom type value elsewhere) easiest way seems to be to use Arrays.stream(resourceTypes).map(Enum::toString) but in that case I'd also change fieldType to String
AdminEvent:

 public static final SearchableModelField<AdminEvent> RESOURCE_TYPE   = new SearchableModelField<>("resourceType", String.class);

Or maybe the cleanest solution (in case we won't support search by custom types) would be to change implementation of MapFieldPredicates:

put(ADMIN_EVENTS_PREDICATES, AdminEvent.SearchableFields.RESOURCE_TYPE, mapAdminEventEntity -> ResourceType.valueOf(mapAdminEventEntity.getResourceType()));

Should this topic be put into its own separate PR?

But with custom types querying starts to be a little bit tricky. In scenario when there is more than one custom resource type and admin events are queried by ResourceType.CUSTOM, all custom events are returned regardless of its actual value. Is this expected behavior?

I honestly have no idea, but this is definitely a strange behavior in my opinion.

Should this topic be put into its own separate PR?

Yeah, I think so. This PR doesn't seem like the proper place to handle these resource type inconsistencies. We should probably discuss that as part of a separate issue.

Is there this issue filed already?

I've created #12485