Similar to: #2534

Problem

The AuditEntry type follows the published response schema of the GET /orgs/:org/audit-log REST API endpoint.

However, making manual requests to the audit log endpoint using specifically the search filter action: org.update_member, the response payload includes extra fields that are not part of this schema.

Example

Make an authenticated request to any enterprise-cloud enabled organization.

GET https://api.github.com/orgs/<org-name>/audit-log?phrase=action:org.update_member

The (redacted) response looks like:

[
  {
    "@timestamp": 1676657306868,
    "_document_id": "<redacted>",
    "action": "org.update_member",
    "actor": "<redacted>",
    "actor_id": 123,
    "actor_location": {
      "country_code": "US"
    },
    "business": "<redacted>",
    "business_id": 123,
    "created_at": 1676657306868,
    "old_permission": "admin",
    "operation_type": "modify",
    "org": "<redacted>",
    "org_id": 123,
    "permission": "read",
    "user": "<redacted>",
    "user_agent": "<redacted>",
    "user_id": 123
  }
]

Removing redacted fields for clarity:

[
  {
    "action": "org.update_member",
    "old_permission": "admin",
    "operation_type": "modify",
    "permission": "read",
    "user": "<redacted>"
  }
]

Note the old_permission and permission fields that are not documented as part of the schema, but are clearly returned as part of this audit log payload. These permission fields are the only indicator of the direction of the org.update_member action, as the operation_type is always modify and the action is always org.update_member for both directions.