Notifications

When someone answers a comment, its author should hear about it, and when someone comments on an article, the article's author should too. buildContentNotifications sets that up for a threaded content type: you name the author fields, the texts and the link, and VitNode sends the notifications through the core notification system, with its bell, inbox, preferences and email.

The server sends them when a comment becomes public, whoever wrote it and however: the shared comment section, your own layout, the public API or the AdminCP. Your React components send nothing, so there is nothing to change in them.

Before you beginCopy Anchor Link

You need:

• The newsroom comments, from Comments. The comment type has author: field.user() and thread: { parent: "parent", root: "article" }.
• Replies, to have replies to notify about. Comment actions is not needed.
• Two member accounts, to see a notification arrive. Nobody is notified about their own comment.

Choose a setupCopy Anchor Link

Pick A when your articles have no single author, for example when staff write them without one or when the author field lists several people. The Blog plugin is in that case: its articles have authorId: field.user({ multiple: true }), so Blog uses setup A. Adding an author field only for notifications is never required.

  fields: {
    title: field.text({ required: true, minLength: 3, maxLength: 200 }),
    // ...
    author: field.user(), 
  },

bun run build:plugins
bun run db:migrate

import { buildContentNotifications } from "@vitnode/core/content/server";

import { articleContentType } from "@/content/article";
import { commentContentType } from "@/content/comment";

export const commentNotifications = buildContentNotifications({
  content: commentContentType,
  root: articleContentType,
  rules: {
    replies: {
      id: "newsroom.comment_reply",
      preset: "threadReply",
      recipients: { authorField: "author" },
      messages: {
        label: "newsroom.notifications.comment_reply.label",
        description: "newsroom.notifications.comment_reply.description",
        comment: "newsroom.notifications.comment_reply.comment",
        reply: "newsroom.notifications.comment_reply.reply",
      },
      target: ({ root, content }) =>
        `/news/${root.slug}#comment-${content.id}`,
      defaults: { inApp: true, email: "none" },
      email: true,
    },
  },
});

import { commentNotifications } from "@/api/lib/notifications"; 
import messages from "@/locales/api"; 

export const newsroomApiPlugin = () =>
  buildApiPlugin({
    manifest,
    contentNotifications: [commentNotifications], 
    messages, 
    modules: [
      // ...unchanged
    ],
  });

{
  "newsroom": {
    "notifications": {
      "comment_reply": {
        "label": "Comments and replies",
        "description": "Someone comments on your article or replies to your comment.",
        "comment": "{actor} commented on \"{title}\"",
        "reply": "{actor} replied to your comment on \"{title}\""
      }
    }
  }
}

import type { LocaleMessagesMap } from "@vitnode/core/lib/i18n/types";

const messages: LocaleMessagesMap = {
  en: async () => await import("./en.json", { with: { type: "json" } }),
};

export default messages;

target: ({ content }) => `/blog/comments/${encodeURIComponent(content.slug)}`,

Who gets notifiedCopy Anchor Link

Ada writes the article, Bob and Cleo are members, and Max is a moderator. Recipients are read from the comment, the comment it answers and the article when the notification is sent, never from anyone's session.

Core then drops deleted accounts, members who turned the type off and anyone who may no longer see the comment.

When it firesCopy Anchor Link

A comment notifies once, the first time it becomes public. VitNode tells that moment apart by the comment's publishedAt, which is set once and never rewritten. A notification already in an inbox is checked again each time the inbox loads and before each email, so it follows what happens to the comment later.

Comments that were already public before you added the rules never notify, so deploying them doesn't bury every author under a year of old news.

The notification is stored in the same database transaction as the comment, and a background task sends it a moment after the response. If the comment's transaction rolls back, nothing is sent. If the task fails, the queue retries it without ever creating a second notification. Notifications API has the details.

Tell authors about moderation decisionsCopy Anchor Link

When comments go through approval, add a moderationDecision rule to tell the person who submitted a comment what a moderator decided. Newsroom comments are never pending, so this example comes from the Forum plugin, whose forums have publishing policies:

decisions: {
  id: "forum.comment_decision",
  preset: "moderationDecision",
  messages: {
    label: "@vitnode/forum.notifications.comment_decision.label",
    approved: "@vitnode/forum.notifications.comment_decision.approved",
    rejected: "@vitnode/forum.notifications.comment_decision.rejected",
  },
  target: ({ content, decision }) =>
    decision.status === "approved"
      ? commentPermalink(content.slug)
      : FORUM_PENDING_HREF,
},

Each decision notifies the submitter once, so a resubmitted comment that is rejected again gets a second notification. A rejected comment is a draft that readers cannot open, so target sends its author to their pending list instead of an anchor the topic page does not have. The texts receive {title}, {kind} (create or edit) and {reason}.

Tell moderators what waits for approvalCopy Anchor Link

The approvalPending preset notifies the moderators who could decide a pending comment or edit, and links to it in the Moderator CP. Add it next to the decisions rule:

pending: {
  id: "forum.comment_pending",
  preset: "approvalPending",
  messages: {
    label: "@vitnode/forum.notifications.comment_pending.label",
    pending: "@vitnode/forum.notifications.comment_pending.pending",
  },
},

"comment_pending": {
  "label": "Comments awaiting approval",
  "pending": "{kind, select, edit {An edit to a comment is waiting for approval in {container}} other {A new comment is waiting for approval in {container}}}"
}

Only moderators whose can_approve covers the comment's forum receive it, and it leaves their inboxes once someone decides. Get notified describes it from the moderator's side, and the Notifications API lists the options.

Preferences and emailCopy Anchor Link

Each rule is an ordinary notification type. Members find Comments and replies under Settings → Notifications and can turn the notification list, push or email on and off for it. Administrators can change the defaults or switch the type off on the AdminCP notifications page. Email needs an email adapter and email: true (or a defaults.email other than "none"); immediate emails and daily or weekly digests then work like every other type.

Check the resultCopy Anchor Link

You need two members, Ada and Grace. For setup B, first make Ada the author of a published article, as in Give articles an author. For setup A, any published article works.

1. Sign in as Grace in another browser and comment on the article. With setup B, Ada's bell shows a new notification within a few seconds:

2. As Ada, open the notification. The article opens with Grace's comment highlighted, even when it is on a later page of comments:

3. As Ada, reply to Grace's comment. Grace gets "replied to your comment" and Ada gets nothing. Open it as Grace, and the reply is highlighted below Grace's comment.
4. As Grace, open Settings → Notifications, expand Comments and replies and turn Notification list off. Have Ada reply again. Nothing new arrives. Turn it back on.
5. As a moderator, hide Grace's comment. Ada's notification now says it is no longer available. Show the comment again and the notification comes back.
6. Delete the article. Both notifications disappear from the inboxes.

RelatedCopy Anchor Link

• Notifications API: every option, custom rules, access and retries.
• Notification types: what a type controls in the core notification system.
• Approvals: when comments wait for a moderator.