ticketlens 0.42.1 → 0.42.2

package/README.md

@@ -499,7 +499,7 @@ Write directly to the ticket in its real tracker — Jira, GitHub, or Linear —
 
 `ticketlens transition` with just a ticket key lists the tracker's current valid options without changing anything (Jira: real workflow transitions for that issue; GitHub: open/closed; Linear: team-scoped workflow states). Add both `--target` and `--confirm` to execute — `--confirm` is a deliberate two-step gate: a behavioral nudge and forensic trail, not a hard security guarantee. Every write, once resolved, is re-validated against the tracker's current state immediately before executing — never a blind write against a stale option.
 
-`ticketlens assign --to=me` self-assigns immediately, no `--confirm` needed. Any other `--to` (a name or email) assigns to another developer — Jira Cloud only for now, GitHub/Linear/Server-DC refuse cleanly. It searches Jira's real assignable-user list first: without `--confirm` it only lists the matching candidate(s), never assigns; with `--confirm` it executes only if exactly one candidate still matches (0 or 2+ always refuses). Matches are cached locally per project for 3 days.
+`ticketlens assign --to=me` self-assigns immediately, no `--confirm` needed. Any other `--to` (a name or email) assigns to another developer on Jira (Cloud and Server/DC) — GitHub/Linear refuse cleanly. It searches Jira's real assignable-user list first: without `--confirm` it only lists the matching candidate(s), never assigns; with `--confirm` it executes only if exactly one candidate still matches (0 or 2+ always refuses). Matches are cached locally per project for 3 days.
 
 `ticketlens worklog` (or `tl worklog`) logs time on Jira tickets, always as you.
 
@@ -1121,7 +1121,8 @@ npm test
 See [ROADMAP.md](ROADMAP.md) for the full plan.
 
 Recently shipped:
-- **`ticketlens assign --to="name or email"`** — assign a ticket to another developer, not just yourself. Jira Cloud only for now; searches real assignable users first, lists matches, executes only on one confirmed match. Pro tier
+- **`ticketlens update --priority`** — a bad priority name now tells you the project's real, current valid options instead of a bare tracker error
+- **`ticketlens assign --to="name or email"`** — assign a ticket to another developer, not just yourself. Jira (Cloud + Server/DC); searches real assignable users first, lists matches, executes only on one confirmed match. Pro tier
 - **Console: Recall "select all N matching" bulk delete** — Gmail-style banner deletes every note matching your search/filters across all pages, not just the current one
 - **Recall Stop-hook fix** — the end-of-session Recall reminder no longer fires because of file writes; only real ticket writes (comment, transition, assign, update) arm it. Also hardened against malformed transcripts and a session-id path-collision bug found by adversarial testing
 - **Console: no repeat request on same-page menu clicks** — sidebar links, the header gear and Settings tabs skip the request when they point at the page you are on

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ticketlens",
-  "version": "0.42.1",
+  "version": "0.42.2",
   "description": "Jira CLI for developers — fetch ticket context, triage your queue, and stop tab-switching. Zero dependencies, all local.",
   "type": "module",
   "bin": {

package/skills/jtb/SKILL.md

@@ -1,4 +1,4 @@
-<!-- jtb-skill-version: 0.46.0 -->
+<!-- jtb-skill-version: 0.47.0 -->
 ---
 name: jtb
 description: Fetch a Jira ticket's full context (description, comments, linked issues, code references) and assemble a structured TicketBrief for implementation planning. Use when user types /jtb, mentions a Jira ticket key, or wants to plan work from a Jira ticket.
@@ -438,7 +438,7 @@ ticketlens transition PROD-1234                              # list valid transi
 ticketlens transition PROD-1234 --target="Done" --confirm    # execute
 ticketlens assign PROD-1234 --to=me                          # assign to yourself — immediate, no --confirm
 ticketlens assign PROD-1234 --to="Jane Dev"                  # search assignable users — read-only, lists match(es)
-ticketlens assign PROD-1234 --to="Jane Dev" --confirm        # execute — only if exactly one match (Jira Cloud only)
+ticketlens assign PROD-1234 --to="Jane Dev" --confirm        # execute — only if exactly one match (Jira only)
 ticketlens duplicates PROD-1234                               # find likely duplicates — read-only
 ticketlens link PROD-1234 PROD-5678                            # list valid link types — read-only
 ticketlens link PROD-1234 PROD-5678 --type="Duplicate" --confirm  # execute the link
@@ -453,7 +453,7 @@ ticketlens worklog PROD-1234=1h30m PROD-5678=45m --comment="Sprint work" --confi
 
 `transition` called with just a ticket key never mutates anything — it lists the tracker's current valid options (Jira: real workflow transitions for that issue; GitHub: open/closed; Linear: team-scoped workflow states). Only add `--target` **and** `--confirm` once the target has actually been confirmed with the user — `--confirm` is a deliberate two-step gate, not a formality to route around. Never guess a `--target` value; always list first, then use one of the names shown.
 
-`assign` — `--to=me` self-assigns immediately, no `--confirm` needed. Any other `--to` (a name or email) assigns to another developer, Jira Cloud only for now — GitHub, Linear, and Jira Server/DC refuse cleanly rather than guess at unverified API behavior. It searches Jira's real assignable-user list first: called without `--confirm` it never assigns, only lists the matching candidate(s) (name + accountId, cached locally per project for 3 days); called again with the same `--to` and `--confirm`, it executes only if exactly one candidate still matches — 0 or 2+ matches always refuses, never guesses which person was meant. Never attempt a workaround (e.g. via `comment`) for a tracker `assign` refuses (GitHub/Linear/Server-DC) — tell the user it isn't supported yet.
+`assign` — `--to=me` self-assigns immediately, no `--confirm` needed. Any other `--to` (a name or email) assigns to another developer on Jira (Cloud and Server/DC) — GitHub and Linear refuse cleanly rather than guess at unverified API behavior. It searches Jira's real assignable-user list first: called without `--confirm` it never assigns, only lists the matching candidate(s) (name + accountId, cached locally per project for 3 days); called again with the same `--to` and `--confirm`, it executes only if exactly one candidate still matches — 0 or 2+ matches always refuses, never guesses which person was meant. Never attempt a workaround (e.g. via `comment`) for a tracker `assign` refuses (GitHub/Linear) — tell the user it isn't supported yet.
 
 `duplicates` lists likely-duplicate tickets in the same project. On Jira, any ticket already linked as a "Duplicate" is always listed first — that's a confirmed relationship a human already recorded, not a heuristic. Everything else is ranked by local title/description overlap — no tracker scores similarity server-side, so treat those as a nudge for the user to check manually, never as a confirmed duplicate to act on unprompted (e.g. don't auto-close or auto-comment based on a match). `--threshold=N` (0–1, default 0.35) tightens or loosens what counts as a text-match — it has no effect on Jira-linked duplicates, which are always shown. An empty result is the same approximation in the other direction — the local scorer can miss a real duplicate too, so don't treat "no likely duplicates found" as proof none exist.
 

package/skills/jtb/scripts/lib/adapters/jira-adapter.mjs

@@ -85,27 +85,33 @@ export function createJiraAdapter(conn, { fetcher = globalThis.fetch } = {}) {
 
     /**
      * Resolves a free-text name/email into candidate assignable users —
-     * read-only, never assigns. Cloud only (`apiVersion === 3`): Jira
-     * Server/DC's equivalent endpoint semantics are unverified, so this
-     * refuses rather than guess at request/response shape (ROADMAP 61).
+     * read-only, never assigns. Cloud (v3) and Server/DC (v2) both use
+     * `GET .../user/assignable/search`; `fetchAssignableUsers` is already
+     * apiVersion-generic (ROADMAP 65) and normalizes both shapes into
+     * {accountId, name, displayName} — Cloud populates accountId, Server/DC
+     * populates name, this method just passes that through unmodified.
      * Caching (3-day TTL, per project+query) is the caller's job — same
      * split as `listIssueTypes`, which is also cache-agnostic here.
      */
     async searchAssignableUsers(key, query, opts = {}) {
-      if (apiVersion !== 3) {
-        throw new Error('Assigning to another developer needs Jira Cloud — Server/DC is not supported yet.');
-      }
       const users = await fetchAssignableUsers(key, query, { ...base, ...opts });
-      return users.map(u => ({ accountId: u.accountId, displayName: u.displayName ?? u.name ?? u.accountId }));
+      return users.map(u => ({ accountId: u.accountId, name: u.name, displayName: u.displayName ?? u.name ?? u.accountId }));
     },
 
     /**
-     * Executes an assignment to a resolved accountId — always Cloud
-     * (`searchAssignableUsers` is the only path that produces one), so no
-     * apiVersion branch is needed here the way `assignToSelf` has.
+     * Executes an assignment to a resolved candidate (from
+     * `searchAssignableUsers`) — same apiVersion field-resolution pattern
+     * `assignToSelf` already uses: accountId for Cloud, name for Server/DC
+     * (ROADMAP 65). Never sends a null identity field — Jira's PUT treats
+     * that as "unassign", not an error (same reasoning as `assignToSelf`).
      */
-    async assignToUser(key, accountId, opts = {}) {
-      await assignIssue(key, { accountId }, { ...base, ...opts });
+    async assignToUser(key, candidate, opts = {}) {
+      const field = apiVersion === 3 ? 'accountId' : 'name';
+      const value = candidate[field];
+      if (!value) {
+        throw new Error(`Cannot resolve candidate's ${field} — Jira did not return it for this connection.`);
+      }
+      await assignIssue(key, { [field]: value }, { ...base, ...opts });
     },
 
     /**

package/skills/jtb/scripts/lib/help.mjs

@@ -671,7 +671,7 @@ export function printMcpHelp({ stream = process.stdout } = {}) {
     `  "not available" instead of an empty result — every other tool needs Pro.`,
     `  ${s.cyan('ticket_transition')} is destructive when called with`,
     `  \`target\`+\`confirm: true\`; ${s.cyan('ticket_assign')}'s \`to: "me"\` self-assigns immediately,`,
-    `  no confirm needed — assigning to another developer (Jira Cloud only) resolves`,
+    `  no confirm needed — assigning to another developer (Jira only) resolves`,
     `  \`to\` first and needs \`confirm: true\` once it matches exactly one candidate;`,
     `  ${s.cyan('ticket_worklog')} is Jira-only, logs as you only, and writes nothing without`,
     `  \`confirm: true\` (it previews instead) — a worklog cannot be deleted through TicketLens;`,
@@ -782,8 +782,8 @@ export function printAssignHelp({ stream = process.stdout } = {}) {
     '',
     `  Assign a ticket directly in its tracker (Jira/GitHub/Linear). ${s.dim('[Pro]')}`,
     `  ${s.brand('--to=me')} self-assigns immediately, no --confirm needed. Any other`,
-    `  ${s.brand('--to')} (a name or email) assigns to another developer — Jira Cloud`,
-    `  only for now. Resolves the name/email against real assignable users first:`,
+    `  ${s.brand('--to')} (a name or email) assigns to another developer on Jira`,
+    `  (Cloud and Server/DC). Resolves the name/email against real assignable users first:`,
     `  without --confirm it lists the match(es) instead of assigning; with`,
     `  --confirm it executes only if exactly one candidate matched. Results are`,
     `  cached locally per project for 3 days.`,

package/skills/jtb/scripts/lib/jira-client.mjs

@@ -622,6 +622,14 @@ export async function assignIssue(ticketKey, assignee, opts = {}) {
  * published spec — there is no "list everyone assignable" mode), so this
  * throws early on an empty query rather than sending a request guaranteed
  * to fail.
+ *
+ * Server/DC (v2) also gets the legacy `username` param alongside `query` —
+ * live-verified against a real Server/DC instance (ROADMAP 65): that
+ * instance silently ignores `query` and only filters on `username`, so
+ * `query`-only returned every assignable user regardless of input.
+ * Sending both is safe on Cloud too (Cloud simply never receives the extra
+ * param, this branch is v2-only) and on any Server/DC version that does
+ * honor `query` (an extra recognized param narrows further, never loosens).
  */
 export async function fetchAssignableUsers(ticketKey, query, opts = {}) {
   const { env = process.env, fetcher = globalThis.fetch, lookup = defaultLookupFor(fetcher), apiVersion = 2, timeoutMs = 10_000, allowPrivateIp = false, maxResults = 20 } = opts;
@@ -630,7 +638,9 @@ export async function fetchAssignableUsers(ticketKey, query, opts = {}) {
   }
   validateBaseUrl(env.JIRA_BASE_URL, allowPrivateIp);
   const baseUrl = env.JIRA_BASE_URL.replace(/\/$/, '');
-  const params = new URLSearchParams({ issueKey: ticketKey, query, maxResults: String(maxResults) });
+  const paramFields = { issueKey: ticketKey, query, maxResults: String(maxResults) };
+  if (apiVersion === 2) paramFields.username = query;
+  const params = new URLSearchParams(paramFields);
   const url = `${baseUrl}/rest/api/${apiVersion}/user/assignable/search?${params}`;
 
   const fetchOpts = { headers: { ...buildAuthHeader(env), 'Content-Type': 'application/json' } };

package/skills/jtb/scripts/lib/mcp-tool-schemas.mjs

@@ -239,12 +239,12 @@ export const TOOLS = [
   },
   {
     name: 'ticket_assign',
-    description: 'Assign a ticket in its tracker (Jira/GitHub/Linear). `to: "me"` self-assigns immediately, no confirm needed. Any other `to` (a name or email) assigns to another developer — Jira Cloud only for now; GitHub, Linear, and Jira Server/DC are refused. Resolves `to` against real assignable users before writing: called without `confirm: true`, it never assigns — it returns the matching candidate(s) (name + accountId) instead, so the exact person can be confirmed first. Called again with the same `to` and `confirm: true`, it executes only if `to` still resolves to exactly one candidate; 0 or 2+ matches always refuses, never guesses. Matches are cached locally per ticket\'s project for 3 days. Requires a TicketLens Pro license.',
+    description: 'Assign a ticket in its tracker (Jira/GitHub/Linear). `to: "me"` self-assigns immediately, no confirm needed. Any other `to` (a name or email) assigns to another developer on Jira (Cloud and Server/DC); GitHub and Linear are refused. Resolves `to` against real assignable users before writing: called without `confirm: true`, it never assigns — it returns the matching candidate(s) (name + accountId) instead, so the exact person can be confirmed first. Called again with the same `to` and `confirm: true`, it executes only if `to` still resolves to exactly one candidate; 0 or 2+ matches always refuses, never guesses. Matches are cached locally per ticket\'s project for 3 days. Requires a TicketLens Pro license.',
     inputSchema: {
       type: 'object',
       properties: {
         ticket: { type: 'string', description: 'Ticket key, e.g. PROJ-123.' },
-        to: { type: 'string', description: '"me" to self-assign, or a name/email to search for and assign to another developer (Jira Cloud only).' },
+        to: { type: 'string', description: '"me" to self-assign, or a name/email to search for and assign to another developer (Jira only).' },
         confirm: { type: 'boolean', description: 'Must be true, alongside a `to` that resolves to exactly one match, to actually execute an assign-to-other. Not needed for `to: "me"`.' },
       },
       required: ['ticket', 'to'],

package/skills/jtb/scripts/lib/ticket-command.mjs

@@ -538,10 +538,9 @@ export async function resolveAssigneeCandidates(adapter, ticketKey, query, {
 
 /**
  * `--to=me` self-assigns immediately — unchanged fast path, no discovery,
- * no confirm. Any other `--to` resolves a real person first (ROADMAP 61):
- * Jira Cloud only (Server/DC's assignable-user search is unverified —
- * refuses cleanly rather than guessing), and only executes when exactly
- * one candidate matches AND --confirm is given, mirroring `transition`'s
+ * no confirm. Any other `--to` resolves a real person first (ROADMAP 61,
+ * extended to Server/DC by ROADMAP 65) and only executes when exactly one
+ * candidate matches AND --confirm is given, mirroring `transition`'s
  * list-then-confirm shape — notifying a colleague deserves the same
  * reviewed-before-write gate as a workflow-state change.
  *
@@ -611,10 +610,6 @@ export async function runTicketAssign(cmdArgs, {
     stream.write(`  Assigning to another developer is Jira-only right now — ${adapter.type} is not supported.\n`);
     return { ok: false };
   }
-  if (conn.auth !== 'cloud') {
-    stream.write('  Assigning to another developer needs Jira Cloud — Server/DC is not supported yet.\n');
-    return { ok: false };
-  }
 
   const s = createStyler({ isTTY: stream.isTTY });
   let candidates;
@@ -632,14 +627,14 @@ export async function runTicketAssign(cmdArgs, {
 
   if (candidates.length > 1) {
     stream.write(`  ${candidates.length} users match "${to}" — narrow the query:\n\n`);
-    for (const c of candidates) stream.write(`    ${s.brand('●')} ${c.displayName}  ${s.dim(c.accountId)}\n`);
+    for (const c of candidates) stream.write(`    ${s.brand('●')} ${c.displayName}  ${s.dim(c.accountId ?? c.name)}\n`);
     return { ok: false };
   }
 
   const [candidate] = candidates;
 
   if (!cmdArgs.includes('--confirm')) {
-    stream.write(`  Match: ${s.bold(candidate.displayName)}  ${s.dim(candidate.accountId)}\n`);
+    stream.write(`  Match: ${s.bold(candidate.displayName)}  ${s.dim(candidate.accountId ?? candidate.name)}\n`);
     stream.write(cliHints
       ? `\n  Run again with --to="${to}" --confirm to execute.\n`
       : `\n  Call again with to="${to}" and confirm: true to execute.\n`);
@@ -655,8 +650,8 @@ export async function runTicketAssign(cmdArgs, {
   }
 
   try {
-    await adapter.assignToUser(ticketKey, candidate.accountId);
-    logActionFn({ ticketKey, action: 'assign', actor, tracker: adapter.type, detail: { assignee: candidate.displayName, accountId: candidate.accountId } }, { configDir });
+    await adapter.assignToUser(ticketKey, candidate);
+    logActionFn({ ticketKey, action: 'assign', actor, tracker: adapter.type, detail: { assignee: candidate.displayName, accountId: candidate.accountId, name: candidate.name } }, { configDir });
     stream.write(`  ${s.green('✔')} ${s.brand(s.bold(ticketKey))} assigned to ${s.bold(candidate.displayName)}.\n`);
     return { ok: true };
   } catch (err) {