# Board Settings Manage planning, notifications, auto-archive, staleness detection, time tracking, and per-column auto-assign rules. import { Aside, Card, CardGrid, Steps } from '@astrojs/starlight/components'; Use board settings to plan one board and control its automatic behavior. Set its target and milestones, post health updates, mute notifications, or configure archival, staleness, time tracking, and assignment rules. ## What this affects Board settings apply to individual boards on a project. They govern default behaviors that are applied consistently across tasks when rules are triggered: - **Archive actions** — Automatically archive old tasks or mark them for archival to keep your board clean. - **Project planning** — Set a target date, track milestones, and post the board's current health. - **Board notifications** — Mute ordinary inbox, email, and push notifications from this board only. - **Staleness rules** — Automatically detect tasks that have been idle for a set period and take action. - **Auto-assign rules** — Set per-column rules so new or unassigned tasks get attention where they belong. - **Time totals** — Optionally show accumulated tracked time on task cards and in table view. - **Synchronized IndexedDB defaults** — For authenticated Board and Table routes, the synchronized IndexedDB read model is now enabled by default to keep data in sync across opened tabs without manual refresh. You can still opt into the local model by using `?local_db=0` in the URL. ## Reach You can open board settings from: - **Ctrl+K command palette** — Search for **"Board settings"** and select your board. The board and team you opened from are now preselected. - **Board menu** — Open a board's menu and choose **Settings**. ```markdown Clear expired backlog and automate housekeeping. Identify tasks that haven't moved recently. Propagate responsibilities to unassigned cards. Keep data in sync across browsers by default for authenticated board and table routes. ``` ## Ticket prefix Each board has a deterministic ticket prefix (e.g., HTPR, YPER4, HYFA). Owners can rename the prefix from board settings without changing existing ticket numbers. Prefixes are 2–5 letters or digits, unique within the team, and appear as live previews. ### How to change a prefix From the app: 1. Open a board. 2. Click **Settings** > **Board** > **General**. 3. Find **Ticket prefix**. 4. Enter a new prefix (2–5 characters, letters or digits) and press Enter. 5. Old ticket IDs continue to resolve, so links, comments, and PRs that reference them stay accurate. From the CLI: ```bash hypertask project update --prefix NEWXY --project 15 ``` The prefix is editable on the **Create board** screen (defaulted to the automatic suggestion) and available to agents via the same `project update --prefix` flag. ### Discovering ticket prefix settings From the command palette, type **"ticket prefix"** to jump to this setting. The search returns **"Settings: Ticket prefix (board)"** for the current board. Use this to quickly locate the prefix configuration when you need to update it. ### Rationale - **Instant updates:** The displayed ID is built from the board's current prefix and the ticket's number, so changing the prefix is a quick update instead of rewriting every ticket. - **Backwards compatibility:** Old ticket IDs keep resolving via aliases, just like old numbers already do. - **Avoid clashes:** Moved tickets take the next free number, so prefixes and numbers never conflict, even after deleting tickets or changing prefixes. ## Board notifications Open **Settings → Board → General**, then turn **Board notifications** off to mute one board. The change applies immediately and persists across refreshes. Muting a board stops its ordinary: - Inbox notifications, including snoozed items returning later. - Push notifications. - Immediate and digest emails. - Assignment, reaction, task-move, and due-date alerts. Your global notification channel settings stay unchanged, and other boards continue notifying you. Direct replies from managed agents still appear in your inbox so an explicit agent request can return its answer. Turn **Board notifications** on again whenever you want to resume delivery. ## Project planning Open **Settings → Board → Planning** to keep the board's outcome and current health in one place. - Set the board's **target date**. - Add dated **milestones**, then mark them complete as the project advances. - Post a short health update as **On track**, **At risk**, or **Off track**. - Review the 20 most recent updates with their author and timestamp. Any board member can read planning and post a health update. Only the board owner or an admin can change the target date or milestones. Target and milestone changes save immediately. Press **Ctrl+Enter** or **Cmd+Enter** to post a health update from the message field. ## Auto-archive Configure automatic archival of tasks that no longer require attention. Archive is different from deletion—it keeps history while removing items from the active view so you don't have to manually clean up stale columns. ### Available options Rules you can set per board: - **Enable auto-archive** — Turn the rule on/off. - **Archive after** — Choose how many days tasks remain before archival. - Common presets: 90, 120, 180, 365. - **Archive unused** — Automatically archive tasks that have not been touched recently (see Staleness). ### How it behaves When a task crosses your configured threshold: - The board removes the task from column counts. - Tasks are moved to the board's Archive section. - History (comments, attachments, subtasks) remains intact. Tasks in any column are eligible: backlog, in-progress, review, and so on. ## Set a column work limit Use a work limit to spot crowded columns without blocking task moves. 1. Open the board and click a column title. 2. In **Manage board columns**, open that column's settings. 3. Enter a positive whole number in **Work limit**. 4. Leave the field to save the limit. The column count shows active tasks / limit and turns red above the limit. The count includes active tasks hidden by filters. Archived and deleted tasks do not count. You can still create and move tasks when the column is over its limit. Clear **Work limit** to remove the limit. The limit belongs to the column, so saved views share it. ## Staleness detection Staleness rules keep track of active tasks that have not been moved, updated, or interacted with in a defined window. This helps surface forgotten items that might need re-evaluation or removal. Configuration: - **Stale after** — Number of days since the last change/due date. - Suggested ranges: 30, 60, 90. - **Auto-assign stale tasks** (Optional) — Toggle the rule that moves or re-assigns stale tasks to a specific column or assignee. - **Stale reminders** (Optional) — Get notified when tasks reach the staleness threshold so you can prioritize review or cleanup. When staleness is enabled, Kanban cards show the task's age on the board before its age in the current column. Fresh cards show muted ages. Cards become amber at the warning threshold and red at the hot threshold. Use Ctrl+K to toggle staleness for the board or the current view. ### Filtering stale vs healthy Every staleness filter is named so that typing **stale** in the filter menu finds all of them: - **Stale in column** — days since the task last changed column, falling back to its creation date if it has never moved. - **Stale without comment** — days since the last comment, falling back to creation if nobody has ever commented. - **Stale on board** — days since the task was created, regardless of activity (not affected by column moves or comments). - **Not stale** — the inverse: both the column age and the comment age are under the warn threshold. This deliberately ignores board age: a long-lived task that is still being moved and discussed is not stale. All four filters apply the per-board staleness threshold automatically, so a filtered board always agrees with the ages shown on the cards. ## Auto-assign rules Define rules that automatically assign or re-assign tasks to specific members. This is useful for ensuring that new pull requests, backlog items, or triage items land with the right people without manual overhead. ### Per-column auto-assign on column move In addition to setting a default for the entire board when a task is created or is unassigned, you can configure a per-column auto-assign rule: whenever a task is moved into this column, it will be assigned to the specified person or group. Ctrl+K "Auto-assign for this column" opens the per-column configuration. To configure per-column auto-assign: 1. From the board or section header, open the context menu (or use Ctrl+K "Auto-assign for this column") and select the section where you want the rule. 2. Pick an assignee (group or individual) to apply as tasks are moved into that column. The assignment is additive and idempotent—moving a task back into another column and then into this column again respects the rule. 3. When the rule applies, all tenants receive a notification and the assignee is messaged in the source channel if notifications are set up for the board. Auto-assign runs within the effective membership and session context enforced for board write access. Use board-visibility gating to control which users gain or retain write access to the board; ID-based attempts outside that context are scoped to the session owner's permissions. ### Calling auto-assign via CLI/MCP When auto-assign is triggered by CLI or MCP tools, the assignee lookup is evaluated in the context of the authenticated user or tool's session. Actions cannot be authorized by leases or background jobs outside that session; approvals are enforced through the board's membership and write-access model. ### How to configure (defaults) - **Target columns** — Specify which columns should apply auto-assign triggers: - Any column that can receive tasks (e.g., In Progress, Review). - **Assign to** — Select a project member or a role-based assignment: - Individual users. - Groups (e.g., "Testers," "Backend team"). - **Optional priority filter** — Apply only to tasks with certain priority levels (e.g., Urgent, High). ### Scenarios - **Backlog channel** — Assign new backlog items to reviewers or maintainers. - **Review overload** — Auto-assign completed items to QA reviewers when they become "In Review". - **Slack alerts** — Combine with board notifications to alert assignees when auto-assign runs. ## Autosave drafts Changes to board settings are saved automatically. If you navigate away or refresh the page, your settings persist: - **No manual save needed** — All toggles, number inputs, and column mappings are applied instantly. - **Revert behavior** — If you make a mistake, the board defaults (detected from project/staleness rules) can be used as a backup; update the offending rule and save again. ## Logging and history Hypertask tracks rule executions at the board level for review: - **Rule runs** — Historically, Hypertask logged rule runs to a log table (Admin role visible). - **Rule hygiene** — To keep logs manageable, Hypertask retains only recent rule executions (e.g., last 14–30 days) on the log table, while preserving a full backup in a more extensive repository for administrative use. ## Synced IndexedDB defaults You can choose between two read models for Boards and Tables: - **Synchronized IndexedDB (default)** — Active when no `?local_db=0` in the URL. Keeps data in sync across opened tabs and browsers smoothly, at the cost of higher CPU and a small memory overhead. Use this if you regularly open the same board in multiple tabs or devices. - **Local IndexedDB (optional)** — Activated by appending `?local_db=0` to the URL. Reads and writes stay in the local browser state, giving high performance with less CPU and a smaller footprint. Data may not reflect changes from other tabs or browsers until you reload. This defaults to the synchronized model for authenticated Board and Table routes. The system preserves the opt-out via URL flags, so local flow can still be opted into for testing or performance-sensitive workflows. ## Auto-error routing targeting Bugs When auto-error tickets are routed to sections, Hypertask now targets the exact Bugs section by default instead of the board's default column. This applies globally for boards with a specific Bugs section. Boards without a clearly defined Bugs section fall back to the current default section behavior. Changes take effect after board settings are saved.