The Discord side

Half of this module lives in Discord. Anyone can file an issue with /task without opening the dashboard, every issue gets a card in a channel, and the card carries the four things people actually do to an issue: move it, take it, comment on it, open it.

Nothing here is a second, lesser copy of the dashboard. It is the same issues, the same board, the same numbers — the card and the page are two windows on one row in a database, and a change made through either shows in the other at once.

References

Every command that acts on an existing issue takes a reference, which is the issue's identifier: WEB-12. Case does not matter, so web-12 is the same issue. A bare number is not a reference — see identifiers.

You rarely have to remember one. reference completes as you type, from this server's issues: open the box and it offers the issues assigned to you first, then the server's most recent ones. Type WEB-1 and it narrows to that project's issues from WEB-1 up; type a bare 12 and it finds the issue with that number whichever project it is in; type words and it searches the titles. Each line reads WEB-12 · Fix the login loop, and picking one fills in the identifier — exactly what you would have typed. Issues that are done are offered only when you name one by its identifier: the other two ways of asking mean the work still on.

The commands

project, state, team and points complete the same way, from what your server actually has — state offers the columns of the project the command already names (the project option on /task list, the reference's own project on /task state), and points offers the rungs of the project's own scale, and nothing at all on a project that does not size its work. due is a date — 2026-03-12 — and never a time of day.

estimate and team change the issue, so they need Edit — own or any. time is the exception: the entry is yours, so Log time is enough to log your own work, and only its author or somebody with Moderate can change it afterwards.

/task carries no default permission, so every member can use it. That is the point: the person who notices the broken thing should be able to write it down. What each subcommand then does is decided by the member's tracker permissions — list and view are open to everybody, create needs Create issues, comment needs Comment, assign is a Claim when you take a free issue and an Edit otherwise, state is a Move into an open column or a Close into a finished one, and request needs Manage customers. The default floor gives every member all of these for their own issues; a role or member row widens it. Managing projects, states, labels and cycles is done on the dashboard. A server that would rather not have the command open to everyone restricts it in Configuration > Commands Settings, like any other command.

Two menu entries sit beside the command, both named Add as task request: one on a message, under right-click > Apps, and one in a ticket's ⋯ menu. Each opens a small form asking which issue the ask belongs to, and records it against the message's author or the ticket's opener — see customers and requests.

The card

One message per issue: in the module's default channel, or in the channel a /task create ran in. The bar down its left is the colour of the state the issue is in, so a channel of cards reads as a board at a glance.

State, Priority and Assignee are always there — an issue nobody has taken reads Unassigned rather than going quiet about it. Due, Cycle, Estimate, Team, Time, Labels and a #2891 badge for anything attached from GitHub appear only when the issue has them. The description is cut to its first 600 characters: the card is a pointer to the issue, not a copy of it, and /task view and the dashboard have the whole of it.

A description written in Markdown is carried onto the card as it was typed, and Discord renders the parts it understands — bold, italics, lists, code. The rest, a task list's checkboxes included, reads there as the plain text it is, which is another reason the card is a pointer rather than the issue.

The due date is written as a plain 2026-09-18 rather than as one of Discord's local timestamps, because a due date has no time of day — rendered in each reader's own zone it would read as the 17th for half the server. It is marked overdue once the day has passed — on the calendar of the timezone set in your server's settings, the same one the dashboard board reads "today" in, so the card and the board always agree — and stops being marked the moment the issue closes.

The assignee is shown as a mention so you can see who it is at a glance, but nothing on a card ever pings: a tracker is not the place a message decides to notify somebody. Notifications are the DMs below.

Under it, four buttons:

The buttons keep working for as long as the message exists — after a bot restart, a month later, on an issue that has been through five states. They carry the issue's id and nothing else, so there is no state to lose. A closed issue keeps them too: Done is a column, not the end of the road, and reopening an issue is picking another column from the same menu.

Comment is open to everyone who can see the card by default — it is on the floor, because answering a question is not a change to the work. State and Assign answer to the same permissions as the subcommands: by default the issue's creator and its assignee can move and close their own; a Contributor role lets you move anybody's, and a Manager role close anybody's. Anybody else pressing them gets a private reply naming the permission they lack, and nothing happens to the issue.

If even reading them should be narrower than that, post the cards in a channel your team can see and others cannot: the module puts them all in one channel precisely so that who sees an issue is a channel permission.

Delete a card by hand and nothing is lost: the issue is untouched, and the next change to it posts a fresh card in place of the one that went.

Turning cards off

A server that tracks in the dashboard, or reads the digest instead, can switch Post a card for each new issue off in the module's settings. From then on a new issue gets no card and no thread, and /task create says so rather than asking for a channel. Nothing already posted is touched: existing cards stay, keep their buttons and keep updating. A card deleted by hand is not posted again while the setting is off.

The channel digest

One message, kept up to date by the bot, that lists a project's open issues by state — the view for the members who never open the dashboard. Pick a channel and a project under Channel digest in the settings, save, and the bot posts it and pins it.

Each state gets its own block, with the state's colour down the side, its name and how many open issues it holds. Up to eight issues are listed per state, most urgent first, each with its priority, its reference, its title and who has it; a busier column says how many more it holds. Closed issues are never shown. As on a card, the names are mentions that never ping.

The digest updates itself whenever an issue in the project is created, edited, moved, archived or deleted — from the dashboard, from /task, from a card button or from an automation — at most once every ten seconds, so dragging a whole column across the board is one edit rather than twenty. A change nobody could see in the digest (a comment, a description, time logged) does not edit it at all, which is why its footer says when the list last changed rather than when the bot last looked.

A few things worth knowing:

• It carries no dates. A digest that said "overdue" would be wrong at midnight with nothing to update it. Due dates are on the cards and the board.
• Delete it and it comes back with the next change. To remove it for good, clear the channel in the settings — the bot takes its message down.
• Move it by picking another channel: the old message is deleted and a new one is posted in the new channel.
• One digest per server. It shows one project; switching the project rewrites the same message.
• Renaming or recolouring a state updates the digest with the cards. Adding, deleting or reordering states shows up with the next issue change.

The bot needs View Channel and Send Messages in that channel to post it, and Pin Messages (or Manage Messages) to pin it — without that it is simply not pinned. If the bot cannot post, the settings save says so.

Linking an issue

The Open button is the link out of Discord, but an issue can also be linked into Discord by anybody, because every issue has a page of its own:

/dashboard/123/tasks/WEB-12

Paste that into a channel, a thread or a commit message and whoever follows it lands on the issue itself — its properties, its sub-issues, its relations and its whole discussion — rather than on a board they then have to search. Copy link in the dashboard's command palette is the fast way to get one. The reader needs access to your server's dashboard, so inside Discord the identifier WEB-12 and /task view are what everybody can follow. See the address of an issue.

The thread

With Create a thread on, FlaviBot opens a thread under each card, named WEB-12 and the issue's title. The thread is where the issue is discussed, and comments written on the dashboard are mirrored into it, so somebody reading in Discord sees the same conversation as somebody reading in a browser.

The channel then stays a list of cards rather than a wall of chat, which is what makes a channel of a hundred issues readable at all.

Threads are best-effort: without Create Public Threads the card is posted and works exactly as it should, and the only difference is that the discussion has nowhere to be mirrored to. Turning the setting off stops new threads; the ones already open stay where they are. Deleting a card's message takes its thread with it, as Discord always does.

A thread archives itself after a week of silence, which is Discord's longest setting — anyone posting in it brings it straight back.

The direct messages

Each one is a card on the rail of the issue's state colour — the same colour as its column on the board. It names the issue, says what happened and who did it (with their avatar), and sums the issue up on one line: project, state, priority, due date. A comment DM quotes the comment. Under it, Open goes to the issue's card in the channel, or to the dashboard when it has no card, next to Mute this issue. The one sent to somebody who asked for the issue carries no mute toggle: they follow nothing, and it is sent once.

Nobody is told about their own action. Taking an issue yourself, moving one yourself or commenting on one sends you nothing: you are looking at the result already, and that is the single most common reason a bot ends up feeling noisy.

Following an issue comes from having been involved with it: you created it, it was assigned to you, or you commented on it. Every one of these is a DM; no task notification is ever posted in a channel, and none of them mentions a role or @everyone. With your DMs closed you simply do not get them, and the card in the channel is still the record.

When a command refuses

A failure to post the card never loses the issue: it is created, it is on the board and in the list, and it simply has no message in Discord.

One bot per server

Issue cards, their threads and their DMs are the work of one bot, named in Settings as the primary bot. A second bot posting the same card would double every message and every DM, and neither could edit the other's.

You do not have to choose one to get started: in a server that has never used the module, the bot that receives the first /task create claims the job, and Settings is where you change your mind afterwards. A server running a single FlaviBot never has to think about this at all.

Changing the primary bot leaves the cards already posted where they are: a message belongs to the application that sent it, and the new bot cannot edit them. New issues get their cards from the new bot; the old cards stay readable, but their buttons now answer that this bot no longer handles tasks here. Switch primary bots between projects rather than in the middle of one. The digest is the exception: the new bot posts its own, and deletes the old one if it has Manage Messages in that channel.

Next: views and shortcuts.