From e15f345b40c041119386608d1df6157ec95c9867 Mon Sep 17 00:00:00 2001 From: Paul Schultz Date: Tue, 3 Dec 2024 17:16:01 -0600 Subject: [PATCH] update README Signed-off-by: Paul Schultz --- docs/backend-system/core-services/auditor.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/backend-system/core-services/auditor.md b/docs/backend-system/core-services/auditor.md index aa62e4f6cf..1a4ed43f76 100644 --- a/docs/backend-system/core-services/auditor.md +++ b/docs/backend-system/core-services/auditor.md @@ -78,11 +78,13 @@ In this example, an audit event is created for each request to `/my-endpoint`. T ## Naming Conventions -When defining `eventId` for your audit events, follow these guidelines: +When defining `eventId` and `subEventId` for your audit events, follow these guidelines: -- Use kebab-case (e.g., `user-login`, `file-download`). +- Use kebab-case (e.g., `user-login`, `file-download`, `fetch`, `entity-create`, `entity-update`). +- The `eventId` represents a logical group of similar events or operations. For example, "fetch" could be used as an `eventId` encompassing various fetch methods like `by-id` or `by-location`. +- Use `subEventId` to further categorize events within a logical group. For example, if the `eventId` is "fetch", the `subEventId` could be "by-id" or "by-location" to specify the method used for fetching. - Avoid redundant prefixes related to the plugin ID, as that context is already provided. -- Choose names that clearly describe the event being audited. +- Choose names that clearly and concisely describe the event being audited. ## Configuring the service