View events refactor

[jdorn]

Features and Changes

Today, only admins can view an audit log of events for their org. This makes sense for events like user.login - we don't want to expose the login ip/userAgent of everyone in the org to non-admins. But for other events like feature.updated, it's too restrictive - we want users to be able to click from a Slack notification and view the event details without being admins.

This PR changes the logic for viewing event details. There are some events that contain sensitive info (like user.login) that we want to keep admin-only. But for everything else, we now use the event subject (e.g. the feature or experiment) to determine view access. If a user is able to view an experiment, they are now also able to view events about that experiment.

1. Add new top-level fields to events: projects, tags, environments, and containsSecrets
2. Simplified webhook filtering logic to use these new fields
3. Replaced permission viewEvents/canViewEvents with viewAuditLogs/canViewAuditLogs
4. Added new permission function canViewEvent(eventPayload) that checks read permission based on the new top-level event fields.

Testing

• Test webhook filtering on project/tag/environment for features
• Test webhook filtering on project/tag/environment for experiments
• Able to view non-sensitive events with readonly role
• Only able to view sensitive events with admin role

[github-actions]

Your preview environment pr-2539-bttf has been deployed.

Preview environment endpoints are available at:

• https://growthbook-3000-pr-2539-bttf.growthbook.okteto.dev
• https://growthbook-3100-pr-2539-bttf.growthbook.okteto.dev

[mknowlton89]

Looks great - simplified quite a bit.

Left one comment for consideration.

[mknowlton89]

Now that this endpoint is filtering the events based on the requester's permission level, it feels like we could loosen the permissions needed to view app.growthbook.io/events.

I could imagine if a user is in the habit of clicking on a Slack notification to view an event, they might find value in being able to view all events (that they have permission to view).

[mknowlton89]

If we do go this route - we will want to conditionally render the export button as we can keep that to admins only.

[jdorn]

I can definitely see the value in seeing a filtered event log for just the things you have access to / care about. Might want to think some more about the best UX for that. I'm not sure sending people to Settings -> Logs is the right solution.

[romain-growthbook]

This looks great. I love the separation of concerns.

One TS remark to leverage types on checking permissions. I think this could be very useful when extending events coverage in the future.

[romain-growthbook]

You could leverage the typing system for this:

type ProtectedEvent = {
  containsSecrets: true,
  ...
}

type UnprotectedEvent = {
  containsSecrets: false,
   ...
}

const unprotectedEventConsumer: (event: UnprotectedEvent) => ...

Then you can add intermediary functions to convert from ProtectedEvent to either UnprotectedEvent or a type that confirms that event permission has been checked.

[jdorn]

I like the idea of leaning on Typescript more. I might save this for a follow up since this PR is already getting quite big