Discussions

The SG-Admin Discussions module — comment moderation, threading, visitor-generated content.

The Discussions module in the admin is the per-site surface for visitor-generated discussion content — comments on posts, threaded replies, moderation queue. Operators review, approve, reply, and moderate from this module. This page is the Reference definition.

What is this for?

Read this page when you want the structural definition of discussion administration — the moderation queue, threading model, and operator actions.

Good use cases

• You are scoping comment-enabled content workflows.
• You are explaining to a stakeholder how SGEN handles visitor comments.
• You hit a "where do moderation flags go?" question.

What NOT to use this for

• Step-by-step procedures — open the relevant Guide.
• Per-release shipped change — open What's New or Changelog.

How this connects to other features

• SG-Admin Overview — parent surface.
• Blogs — posts that often carry discussions.
• Blacklist — at-capture filter that intercepts unwanted comments before they reach the moderation queue.

Where to find it

Open SG-Admin for the active site. Discussions is in the sidebar under the content or moderation group. The moderation queue, approved comments, and spam folder are sub-views. Editor and Admin access can moderate; Authors typically cannot.

Definition

The Discussions module administers comment records. Each comment carries author identity (visitor or registered user), parent post or parent comment (for threading), body content, moderation state (pending / approved / rejected / spam), and timestamp. Operators move comments through the moderation queue and respond inline from the module.

Purpose

Define the Discussions module as a Reference layer.

Scope

Covers the comment record model, moderation queue, threading. Does not cover per-step procedures (Guides) or Blacklist rule configuration (Blacklist Reference).

Comment record + moderation

Record fields

Author, parent post, parent comment (where threaded), body, moderation state, timestamp, IP, email (where collected).

Moderation queue

Default state for new comments depends on per-site configuration: auto-approved, pre-moderated (pending until approved), or filtered through Blacklist rules.

Operator actions

Approve, reject, mark as spam, reply inline, ban author, escalate.

Threading

Replies to comments form a threaded structure. The platform supports a configurable max-depth for threading; deeper replies render flat below the max-depth.

Constraints and boundaries

Discussions is a Reference area for the comment moderation surface.

Do not use for: at-capture filtering (Blacklist), per-step procedures (Guides), per-release shipped change.

Public boundary

This page is intentionally public-safe.

Examples

Example 1 — Operator approves a queued comment

Operator opens the queue, reads the comment, clicks Approve. The comment surfaces on the public post immediately.

Example 2 — Operator marks a comment as spam

Operator marks a borderline comment as Spam. The platform learns the pattern; similar future comments may auto-route to spam state.

Example 3 — Editor replies to a substantive comment

Editor clicks Reply, posts a response inline. The reply renders threaded under the original comment on the public post.

Documentation guidance

Use this page as the structural definition for the Discussions module.

Reading order

Open this page when scoping comment-enabled content workflows.

Related reading

• SG-Admin Overview — parent surface.
• Blogs — posts that carry discussions.
• Blacklist — at-capture filter.

Vocabulary cross-reference

• Comment is one visitor-generated discussion entry.
• Moderation queue is the pending-approval list.
• Threading is the parent-child reply structure.
• Moderation state is one of pending / approved / rejected / spam.

Maintenance discipline

When Discussions changes across releases (new state, new threading depth, new moderation action), update this Reference.

Related reading