Class AuditQuery
Query parameters for retrieving audit entries. Supports both single-value and multi-value filters.
public record AuditQuery : IEquatable<AuditQuery>
- Inheritance
-
AuditQuery
- Implements
- Inherited Members
Properties
Action
public string Action { get; init; }
Property Value
Actions
public string[] Actions { get; init; }
Property Value
- string[]
CallerIdentity
public string CallerIdentity { get; init; }
Property Value
CallerKeyId
Filters entries by the API key Guid string that authenticated the caller (matches CallerKeyId).
public string CallerKeyId { get; init; }
Property Value
CallerSource
public AuditCallerSource? CallerSource { get; init; }
Property Value
CallerType
public AuditCallerType? CallerType { get; init; }
Property Value
CallerUserIdentity
Filters entries by the acting user's authentication subject (matches CallerUserIdentity). Exact match, unlike CallerIdentity.
public string CallerUserIdentity { get; init; }
Property Value
EventType
public AuditEventType? EventType { get; init; }
Property Value
EventTypes
Filters to entries of these types. Takes precedence over EventType.
public AuditEventType[] EventTypes { get; init; }
Property Value
ExcludedEventTypes
Excludes entries of these types. Combines with EventTypes and EventType rather than overriding them.
public AuditEventType[] ExcludedEventTypes { get; init; }
Property Value
ExcludedScopes
Excludes entries whose ScopeChecked is one of these — the access traces a reader does not want, named directly rather than by enumerating everything else.
public string[] ExcludedScopes { get; init; }
Property Value
- string[]
Remarks
An entry that checked no scope is kept. Exclusion is by value, and a consumer-written entry
has no ScopeChecked at all, so excluding audit:read removes the log's readers from the
view without touching the domain entries beside them — which is the whole point of naming the
exclusion instead of building an include list.
Combines with Scopes rather than overriding it: both apply, so an include list can be narrowed further. Naming the same scope in both yields nothing, which is the honest answer.
Feature
public string Feature { get; init; }
Property Value
Features
public string[] Features { get; init; }
Property Value
- string[]
From
public DateTime? From { get; init; }
Property Value
MethodName
public string MethodName { get; init; }
Property Value
Scopes
Filters to entries whose ScopeChecked is one of these. Entries a consumer wrote check no scope, so naming any scope here excludes all of them.
public string[] Scopes { get; init; }
Property Value
- string[]
Skip
public int Skip { get; init; }
Property Value
SortDescending
public bool SortDescending { get; init; }
Property Value
SortField
public string SortField { get; init; }
Property Value
Success
public bool? Success { get; init; }
Property Value
- bool?
Take
public int Take { get; init; }
Property Value
TeamKey
public string TeamKey { get; init; }
Property Value
TeamKeys
public string[] TeamKeys { get; init; }
Property Value
- string[]
To
public DateTime? To { get; init; }