For the complete documentation index, see llms.txt. This page is also available as Markdown.

InfoboardComments

Introduction

InfoboardComments provide discussion on an InfoboardPost. Their visibility always depends on the parent post and can be narrowed by a comment-specific visibility constraint.

Comment author metadata is derived from the authenticated identity and can account for temporary authentication and group-account confirmation.

The text field uses the shared Rich Text HTML format.

Model Definition

Alias

infoboardComment

Relations

Key
Relation
Type
Relation Field(s)

user

Belongs to

user_id

post

Belongs to

post_id

reactions

Morph many

reactions.reactable_type, reactions.reactable_id

currentReaction

Morph one

reactions.reactable_type, reactions.reactable_id, reactions.user_id

Visibility constraint types

  • department - Limit the comment to the author's department.

  • private - Limit the comment to users with the applicable private-comment access and allowed department context.

  • null - Do not impose a comment-specific visibility constraint.

Computed Properties

  • hash - Hashed representation of the comment id.

Capabilities

  • Targetables - Comments inherit visibility from the parent post's Targetables and do not accept independent assignment input.

  • Entity Permissions - Comments inherit channel Entity Permissions through their parent post and do not own independent grants.

  • URL Context - Comment URLs resolve to access-checked context information.

  • Translations - The text field is translatable.

  • Notifications - Creating or changing comment text can notify eligible users connected to the parent post when its channel enables notifications.

  • Reactions - Comments accept reactions when their parent post allows them.

List

List InfoboardComments visible to the current authenticated User.

Definition

GET /api/infoboard/posts/comments

Behavior

  • A comment must be visible through its parent post and satisfy its own visibility_constraint_type.

  • Comment owners, parent-post owners, and explicit entity grants can provide additional access where the applicable permission strategy allows it.

Example Request

Example Response

List by Post

List visible InfoboardComments for one InfoboardPost.

Definition

GET /api/infoboard/posts/{infoboardPost}/comments

Route Parameters

Parameter
Type
Description

infoboardPost

integer | string

InfoboardPost ID or hash.

Behavior

  • The parent post and every returned comment must be visible to the authenticated user.

Example Request

Example Response

Show

Show one visible InfoboardComment by ID or hash.

Definition

GET /api/infoboard/posts/comments/{infoboardComment}

Route Parameters

Parameter
Type
Description

infoboardComment

integer | string

InfoboardComment ID or hash.

Behavior

  • Parent-post visibility and the comment's visibility constraint both apply.

Example Request

Example Response

Create

Create a new InfoboardComment for one InfoboardPost.

Definition

POST /api/infoboard/posts/{infoboardPost}/comments

Route Parameters

Parameter
Type
Description

infoboardPost

integer | string

InfoboardPost ID or hash.

Request Keys

Key
Type
Default
Description

lang_id

string

system language

Language key for the translatable comment text.

text*

string

-

Comment content, which can contain HTML.

visibility_constraint_type

string | null

null

Visibility constraint for the comment.

Keys with * are required.

Behavior

  • The parent post must allow comments, and the authenticated real user must be permitted to comment on it.

  • post_id, department_id, user_id, and group_account_user_id are derived from the route and authenticated identity; client-provided values are replaced.

  • When the post requires user confirmation, the active confirmed user must be a non-group account. Otherwise the real authenticated user becomes the author.

  • When the post forces its comment visibility constraint, the post's comment_visibility_constraint_type replaces the client value.

  • Creating a comment can trigger notifications for eligible users connected to the parent post.

Example Request

Example Response

Reset Relations

Reset selected dependent relations of an InfoboardComment.

Definition

POST /api/infoboard/posts/comments/{infoboardComment}/reset

Route Parameters

Parameter
Type
Description

infoboardComment

integer | string

InfoboardComment ID or hash.

Request Keys

Key
Type
Default
Description

reactions

boolean

false

Delete reactions when true.

Behavior

  • reactions must be true; otherwise no relation is reset and the operation returns an error response.

Example Request

Example Response

Update

Update an existing InfoboardComment.

Definition

PUT /api/infoboard/posts/comments/{infoboardComment}

Route Parameters

Parameter
Type
Description

infoboardComment

integer | string

InfoboardComment ID or hash.

Request Keys

Key
Type
Description

lang_id

string

Language key for the translatable comment text.

text

string

Comment content, which can contain HTML.

visibility_constraint_type

string | null

Visibility constraint for the comment.

Behavior

  • post_id cannot be changed. Client-provided author and department fields are removed.

  • Changing text updates user_id, group_account_user_id, and department_id from the authenticated identity and can trigger updated-comment notifications.

  • Changing text removes its stored translations.

  • visibility_constraint_type cannot be changed while the parent post forces its configured comment constraint.

Example Request

Example Response

Delete

Delete an existing InfoboardComment.

Definition

DELETE /api/infoboard/posts/comments/{infoboardComment}

Route Parameters

Parameter
Type
Description

infoboardComment

integer | string

InfoboardComment ID or hash.

Behavior

  • The comment is soft-deleted, and notifications targeting it are deleted.

  • When the parent post does not require user confirmation, authorization uses the real authenticated user rather than a leftover temporary identity.

Example Request

Example Response

Last updated