Logs

We use Elasticsearch for logging. We log all create, update, and delete operations; however, view operations are not logged. Logging is implemented in both resolvers and open API methods.

Two Types of Logs

The system maintains two distinct logging mechanisms:

1. Operational Logs (CRUD Logs) – Track create, update, delete operations in CRM modules.

2. Client Activity Logs – Track all client and manager activity related to a specific client across CRM, Tradersroom, and Terminal.

The sections below describe both mechanisms.

List of fields:

1. Initiator - shows the user’s name followed by their ID in parentheses (for example, Ethan Reynolds (65a52b15266d8cfb756ed675)). If no ID is provided, the placeholder text "NO_USER_SPECIFIED" or "-" will be used. For specific cases involving the transaction model, particularly in webhooks, the initiator can be "Fireblocks" or "Huntli."
   
   
2. Business model - refers to a distinct, independent model within our CRM, such as "Projects," "Settings," or "Client Area." A business model can also include submodules.
   
   
3. Sub model - specific model that belongs to a business model. For example, "Texts" is a sub model that belongs to the "Settings" business model.
   
   
4. Action - the type of operation being logged. The actions we track include "create," "update," "updateMany," and "delete."
   
   
5. Type - сan be either "internal" or "external." Internal logs are used for internal requests within resolvers, while external logs are associated with open API methods.
   
   
6. Sub type - defines whether the log is an "info" log or an "error" log. Typically, error logs are generated in the "catch" block of a "try-catch" construction, while info logs provide general informational messages.
   
   
7. Description - this field is used for providing additional details in specific cases where the standard information may not be sufficient. For example, in transaction webhooks, the description might include the current transaction status, such as "Sending transaction to Huntli," or detail a specific error, such as "Error while trying to send transaction to Huntli."
   
   
8. Error - is a stringified field containing the error message. It is used in the "catch" block of a "try-catch" construction, with a Sub type of "error."

Filters 

Use filters to narrow log entries by module, operation, source, and time.

Available filters:

1. Business model – Top-level system module (e.g. Desks, Projects, Clients, Businesses).

2. Action – Operation type: create, update, updateMany, delete.

3. Type – Log origin: internal (resolvers/system) or external (Open API, webhooks).

4. Sub type – Log level: info or error.

5. Created date – Date range when the log was generated.

Select one or more criteria and click Save to apply filters. Multiple filters can be combined to quickly isolate relevant logs for debugging, audits, or incident analysis.

Client Activity Logs (Sessions Tab)

Client Activity Logs provide a unified audit trail of all activity related to a specific client.

Unlike Operational Logs (CRUD), Client Activity Logs include:

1. Client actions (CRM / Tradersroom / Terminal)

2. Manager actions performed on that client

3. Navigation and UI events

4. Trading terminal activity

5. Finance flows

6. Support interactions

These logs are displayed in: /clients/edit/{clientId}/sessions

Example: /clients/edit/69732d9afe88d5e6ca56e366/sessions

Data Storage Model

Client Activity Logs are stored in a centralized activity log model with the following structure:

1. clientId

2. actorType (client | manager | system)

3. actorId (optional for client)

4. actorName (for manager display)

5. sourceApp (crm | tradersroom | terminal)

6. eventName (machine-readable)

7. message (human-readable)

8. metadata (JSON object)

9. createdAt (timestamp)

Sessions Table (UI)

The Sessions tab displays:

1. Date/time (default sorting: DESC)

2. Actor type (Client / Manager)

3. Actor (Manager name + ID or “Client”)

4. Source app (CRM / Tradersroom / Terminal)

5. Event type

6. Event details

7. Expandable metadata (JSON)

Table supports:

1. Server-side pagination

2. Sorting by Date

3. Filtering by:

   1. Actor type

   2. Source app

   3. Event type

Logged Client Events

The system logs (minimum):

Authentication:

1. Client registered

2. Client logged in

3. Client requested password reset

4. Client restored password

5. Client changed language

Navigation:

1. Client entered route X

2. Client opened modal/drawer X

3. Client opened Notifications dropdown

4. Client attempted PWA install (result logged)

Transactions:

1. Client submitted deposit

2. Client submitted withdrawal

3. Client fulfilled withdrawal

4. Client filtered transactions

5. Client paginated transactions

6. Client opened transaction details

7. Client declined transaction

Documents:

1. Client fulfilled declaration

2. Client printed form

3. Client downloaded document

Tickets:

1. Client created ticket

2. Client messaged in ticket

3. Client closed ticket

Profile: Client edited profile (log changed fields only, not sensitive values)

Search: Client searched trading ideas/calendar

Trading Terminal

All terminal operations must be logged, including:

1. Order creation

2. Order modification

3. Order cancellation

4. Order execution

5. Symbol changes

6. Indicator changes

7. Chart timeframe changes

8. Widget operations

9. Position lifecycle

10. Filters and instrument selection

Full coverage is mandatory.

Logged Manager Events on Client

All manager actions related to the client must be logged, including:

1. Opened client card

2. Opened client in new tab

3. Edited client data (with safe diff)

4. Created related entity (ticket, note, action, etc.)

5. Updated related entity

6. Bulk operations affecting the client

Each manager event includes:

1. managerId

2. managerName

3. clientId

4. action type

5. target entity (type + id)

6. before/after diff (without sensitive data)

Security & Privacy Rules

1. No passwords, tokens, or full payment data are logged.

2. For profile edits, only changed field names are logged.

3. Access to Sessions tab is role-based.

Difference Between Operational Logs and Client Activity Logs