Chat in AceDraft for Teams: Threads, Roles, Reply Modes

Chat cuts a message at 4,000 characters and says nothing about it. Paste something longer and the tail is gone before the row is written. I'd rather you read that in line one than meet it in a thread you can't edit. I haven't watched this page run. I read its code on 19 September 2026, and everything below is what the code says.

Key takeaways

One page, three roles. The list you get is filtered by who you are, on the server.
Five thread types: a student's line to the org, a group per batch, a moderator's line to the admins, and two announcement threads.
A moderator reaches a student thread or a batch group only when an admin adds them to it by name.
Limitation: message text is trimmed to 4,000 characters with no warning to the sender.
Limitation: switching a thread to read-only doesn't close a window that's already open. That check runs when the connection is made.

Prerequisites. A signed-in enterprise account in any of the three roles, and an organisation. With none linked, the endpoint returns an empty list and the page reads "No conversations yet."

Who can open the chat page?

All three roles. Most enterprise routes name only the admin, so chat is the odd one: the route lists admin, moderator and student together. What changes per role is the list, not the door. The heading says Messages, which is worth knowing if you also use the admin-only Review requests page.

The five kinds of thread

Each conversation is one of these, and the type decides its audience.

Student line. One continuous thread per student, made the first time they open chat.
Batch group. One per batch, made by an admin, with everyone in the batch as audience.
Moderator line. A moderator's own thread to the org's admins, made for them on first open.
Announcements to students and announcements to moderators: one of each per organisation, both born read-only.

The first three are born open. Announcements start locked because they exist to be broadcast, and an admin has to deliberately flip one before anyone answers back.

What lands in your list

An admin sees every thread in the organisation, with write access to all of them.

A moderator sees three things: their own line to the admins, the moderators' announcement thread, and any thread an admin added them to. A request for anything else is refused rather than told it exists.

A student sees their own line, the group for each batch they're in, and the students' announcement thread. The moderators' thread is out of reach for them at any reply mode.

Rows sort by newest message and carry a preview line. The unread badge stops counting out loud at 99+.

Sending a message, and where it stops

The composer only appears if you currently have write access. When it doesn't, a grey strip names the reason: an admin set the thread read-only, or you hold read access and should ask for write.

A banner above the box reports the live connection as connecting or disconnected, and both the input and Send stay disabled until it's open. Drop out and the page retries three times with a lengthening pause, then gives up. Reopening the thread starts it over.

Your own message shows up at once in a faded bubble marked Sending… and is swapped for the stored one when the server echoes it back. Text is trimmed at both ends first, so a message of only spaces disappears silently, and then comes that 4,000-character cut.

History arrives 50 at a time. Scroll near the top of the pane and the next 50 load above it with your position held. The server won't hand over more than 100 in one request whatever is asked.

The four admin controls

Four things. Make read-only flips the open thread and back, and it's hidden on a moderator's own line, which can't be muted from here. Add moderator grants write access on this thread to a name from your moderator list; doing it twice is harmless and answers that they already have access. The group icon builds a thread for a batch you pick. Two buttons in the left rail open the announcement threads, creating them the first time.

No remove control lives on this page. The backend can drop a moderator from a thread, but nothing in the screen calls it, so a grant given here is a grant kept.

How does suspending a student work?

A moderator gets a Suspend user button on a student line or a batch group, nowhere else. In a group they choose the student from the batch roster, which loads only if an admin already gave them batch access; without it, the panel says to go ask.

Start and end are both required, the end has to be later, and the window can run at most 7 days. The browser blocks a bad range and the server re-checks the same rule, plus whether that student really is part of that thread.

A suspended student keeps reading and loses writing; a live send comes back refused. Only an admin lifts it, from the amber strip at the top, which names each suspension by user number rather than by person. Useful once you know the number.

Who this page is for

Use it when the conversation should outlive the review that started it, because every thread here is stored and keeps its history. Skip it for anything you'd attach a file to: this composer takes one line of text and nothing else.

Chat in AceDraft for Teams: Threads, Roles and Reply Modes