[jira] [Created] (SYNCOPE-1981) Search audit events by who (the principal that performed the operation)

["Oleg Zimakov (Jira)" <ji...@apache.org>]

Oleg Zimakov created SYNCOPE-1981:
-------------------------------------

             Summary: Search audit events by who (the principal that performed the operation)
                 Key: SYNCOPE-1981
                 URL: https://issues.apache.org/jira/browse/SYNCOPE-1981
             Project: Syncope
          Issue Type: Improvement
          Components: core
            Reporter: Oleg Zimakov


h2. Background

Every audit event records the principal that *performed* the operation in the \{{AuditEvent.who}} column (NOT NULL, populated on every write). The audit search API (GET /audit/auditEvents, backed by AuditQuery) currently allows filtering by \{{entityKey}}, \{{type}}, \{{category}}, \{{subcategory}}, \{{op}}, \{{outcome}} and a \{{before}}/\{{after}} timeframe — but *not by \{{who}}*. There is no way to answer "what did administrator X do", which is particularly useful when X's account has since been deleted and its \{{entityKey}} (UUID) is no longer known.

h2. Proposal

Add a \{{who}} filter to the audit search API that matches the \{{AuditEvent.who}} column, supporting:
* exact match — \{{who=jsmith}}
* multiple values, OR-combined — \{{who=jsmith&who=admin}}
* \{{*}} wildcards — \{{who=svc-*}}

{\{who}} composes (AND) with all existing filters. When absent/empty, behavior is unchanged (fully backward compatible).

h2. Scope

* REST bean (\{{AuditQuery}}), REST impl (\{{AuditServiceImpl}}), logic (\{{AuditLogic}}), DAO interface (\{{AuditEventDAO}}) and *all four* implementations: JPA, Neo4j, Elasticsearch, OpenSearch.
* Integration tests in \{{AuditITCase}}.
* Wildcard values are escaped so that only \{{*}} acts as a wildcard; all values are parameter-bound (no SQL / Cypher / regex injection). The JPA \{{LIKE}} predicate uses \{{ESCAPE '#'}} for cross-database portability.

h2. Out of scope

* A general Admin Console audit-search page (a separate, larger feature).
* Adding a database index on \{{who}} (optional follow-up; no schema migration is performed here).

h2. Backward compatibility

Purely additive query parameter; existing clients and queries are unaffected. No database migration — the \{{who}} column already exists and is populated.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)