Comment on a ticket

Write comments with the right audience, mention people to share the ticket, attach files, and know who is told by email.

Written for
user
Roles
owner, admin, member, project-manager, elevated-client-user, client-user
Requires
Anyone who can see the ticket; the audiences you may write to follow your role
Feature
tickets

Comments are the conversation on a ticket. Each comment has an audience that decides who can read it, so the same ticket can carry a conversation with the client and a discussion between colleagues without two systems. Comments cannot be edited or deleted after they are posted.

Before you start

You need to be able to see the ticket. Which audiences you may write to is the same as which you may read:

Audience Who reads it (and may write it)
Shared Everyone who can see the ticket: workspace users, elevated and regular client users, and email correspondents on the ticket. Outbound email may carry it.
Internal Workspace users, and client users elevated on the ticket's project. Never regular client users.
Staff Workspace users only (Owner, Admin, Member). No client user, elevated or not.

A viewer reads the audiences their own role allows: a workspace user shared into a ticket outside their projects reads everything; a regular client user reads Shared only.

Steps

  1. Open the ticket and scroll to Write a comment below the timeline.
  2. Choose the Audience: Shared, Internal, or Staff. Audiences you may not use are greyed out with the reason. The line under the control shows who will read the comment, for example "Visible to: 3 workspace users, 1 person at Acme".
  3. Write the comment. Markdown is supported. Select Preview to see it rendered, Edit to go back.
  4. Optionally Mention people: choose a person and select Add. Optionally Attach a file.
  5. Select Comment, or press ⌘Enter (Ctrl+Enter). If a mention would share the ticket with someone new, a confirmation appears first: "Share this ticket with one person?" with the note "They become viewers: they will see the ticket and every Shared comment on it, and they are told by email." Select Share to post, or Cancel.

Rules

  • Default audience. The composer preselects Shared on a ticket started by a client user or by email, and Internal otherwise. If you may not write to that audience, the first audience you may use is selected.
  • Mentions are sharing. A mention does not ping someone who already reads the ticket; it grants them access as a viewer, records "shared the ticket with" in the timeline, and emails them. Mentions are applied before the comment is saved: if any mention is refused ("You cannot share this ticket with Kari Nordmann."), nothing is posted. Who you may mention follows the rules in Share a ticket with viewers.
  • Markdown. Paragraphs, emphasis, headings, lists, task lists (shown as read-only checkboxes), blockquotes, code, tables, horizontal rules, and links. Links open in a new tab and carry no referrer. Images, raw HTML, scripts, styles, and forms are removed when the comment is rendered.
  • Attachments. Files are uploaded when you pick them and attached to the comment when you post it. They take the comment's audience. A comment may be empty if it carries at least one attachment. See Attach files.
  • Limits. A comment is at most 50 000 characters, with at most 20 mentions and 20 attachments.
  • No editing or deleting. Post a new comment to correct an earlier one. An Owner or Admin can redact the whole ticket if content must go; see Archive and delete a ticket.
  • The timeline. Comments and events are shown in one list, oldest first. Show switches between All, Comments, and Activity. Each comment carries its audience badge and the author; a comment that arrived by email is marked "via email" and shows the sender's name or address when the sender has no login.
  • Email. Notification emails are sent as replies in the ticket's thread through the workspace mailbox. A reply to such an email lands as a comment at the audience the sender is allowed to use; a reply that would land at an audience the sender may not use goes to restricted review instead. Email correspondents without a login (contacts) receive Shared comments by email. See Email notifications.

Who is told

A comment is emailed to the assignee, the reporter, and the viewers who may read that audience, except the author. People whose preference is "Mentions and assignments only" get comment emails only on tickets assigned to them; people set to "None" get nothing. Mentioned people get a mention email instead of the comment email. Recipients are decided when the email is sent, so someone who has lost access in the meantime gets nothing.

Examples

A Support ticket started by a client: you reply in Shared so the client reads it and receives it by email. You then switch to Staff to ask a colleague how to price the extra work; the client never sees that.

Through the API: POST /api/w/acme/tickets/ACME-184/comments with {"body": "Deployed to staging.", "audience": "internal"}. Omit audience to use the default. See the API reference.

Common problems

  • "Shared comments are not available here." / "Internal comments are for workspace users and elevated client users." / "Staff comments are for workspace users only." The audience is outside what your role may write on this ticket.
  • "You cannot write comments with that audience on this ticket." The same rule, reported by the server (typically through the API).
  • "Write something first." The comment is empty and has no attachment.
  • "The comment is too long." Over 50 000 characters.
  • "You cannot share this ticket with Kari Nordmann." The mention would share the ticket with someone you may not share with; remove the mention.
  • My comment was posted but the client did not get an email. Check the audience: only Shared comments reach regular client users and contacts. Also check that a mailbox is connected for the workspace.