Skip to content

fix: send workspace create/update notifications to template admins only #16071

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

DanielleMaywood
Copy link
Contributor

Relates to #15845

Rather than sending the notification to the user, we send it to the template admins. We also do not send it to the person that created the request.

@DanielleMaywood DanielleMaywood marked this pull request as ready for review January 8, 2025 15:23
Copy link
Contributor

@dannykopping dannykopping left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm nervous about this notification being enabled by default.

It will get very noisy in large environments, and will be fairly low signal. Only if an admin explicitly wants to add an integration should they enable this, and likely with webhooks only.

WDYT @bpmct @DanielleMaywood think about disabling this notification by default?

We don't really have a precedent for this (i.e. disabling a notification by default), but now might be the time to introduce it.
Blowing up the scope is better than blowing up admins' mailboxes, IMHO.

This PR largely LGTM modulo some minor points, but I'm blocking its merging until we come to a conclusion on the above.

@DanielleMaywood
Copy link
Contributor Author

WDYT @bpmct @DanielleMaywood think about disabling this notification by default?

I'm in two minds about this:

  • If an operator is unhappy about the volume they could always disable it when/if it becomes an issue.
  • We should aim to have nice defaults, so disabling it by default avoids this unhappy path.

@dannykopping
Copy link
Contributor

I'm a big fan of Principle of Least Surprise. I think for existing customers who upgrade to a more recent version and now start getting hundreds of emails they didn't expect violates that principle.

@bpmct
Copy link
Member

bpmct commented Jan 9, 2025

Hey folks - apologies for the confusion here. Let's disable this notification by default both for users and admins. In fact, we should probably not make it available for users to configure. The second point is less important to me, but I just can't think of a good use case for it.

Some of these notifications are really interesting from a webhook POV (fails, creates/updates to an external system) but emails themselves with no filtering would create a lot of spam.

@dannykopping
Copy link
Contributor

Let's disable this notification by default both for users and admins.

Sounds good 👍 thanks @bpmct - and no need to apologise!

In fact, we should probably not make it available for users to configure.

Fortunately, regular (unprivileged) users will only be able to modify their own workspaces, and we're now inhibiting these notifications if the initiator is owner of the workspace; so we won't have to build in this out.

DanielleMaywood added a commit that referenced this pull request Jan 13, 2025
Change as part of #16071

It has been decided that we want to be able to have some notification
templates be disabled _by default_
#16071 (comment).

This adds a new column (`enabled_by_default`) to
`notification_templates` that defaults to `TRUE`. It also modifies the
`inhibit_enqueue_if_disabled` function to reject notifications for
templates that have `enabled_by_default = FALSE` with the user not
explicitly enabling it.
Copy link
Contributor

@dannykopping dannykopping left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@DanielleMaywood DanielleMaywood merged commit 3e3de05 into main Jan 15, 2025
31 checks passed
@DanielleMaywood DanielleMaywood deleted the dm-send-workspace-created-update-notifications-to-template-admins-only branch January 15, 2025 17:43
@github-actions github-actions bot locked and limited conversation to collaborators Jan 15, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants