Skip to content

Dev portal 4/4: feature-request intake with admin convert-to-GitHub-issue#234

Open
dmccoystephenson wants to merge 1 commit into
feature/dev-claimsfrom
feature/dev-feature-requests
Open

Dev portal 4/4: feature-request intake with admin convert-to-GitHub-issue#234
dmccoystephenson wants to merge 1 commit into
feature/dev-claimsfrom
feature/dev-feature-requests

Conversation

@dmccoystephenson

Copy link
Copy Markdown
Member

Summary

Stacked on #233. Fourth and final phase of the dev-portal plan.

  • FeatureRequest — a community-submitted idea scoped to a repo, not yet a GitHub issue.
  • Upvotes reuse the existing like mechanism again (targetType: 'feature_request', keyed by the request's id) — third reuse of the same primitive, no new voting table.
  • POST /api/v1/feature-requests (auth) to submit, GET /api/v1/feature-requests (public) to browse.
  • POST /api/v1/feature-requests/{id}/convert — admin-only (dpc.admin.usernames allowlist, empty by default so nobody can convert until it's set), calls a new write-side GitHubIssueClient to create the real issue. Idempotent: converting an already-converted request just returns it rather than creating a duplicate issue.
  • /dev gets a "Feature requests" section: a submission form plus a list with upvotes and (for signed-in users — the actual admin check is server-side, so the client never needs to know who's an admin) a "Convert to GitHub issue" button that a non-admin will just get a clear 403 from.

Why

This is the "surface feature requests" half of the original ask, and it's designed so an idea's endpoint is always a real GitHub issue — this is intake, not a second, parallel backlog living forever in dpc-api.

Test plan

  • ./mvnw test — 153 tests, 0 failures (1 skip, same as main)
  • npm run lint — clean
  • npm test — 103 tests, 0 failures
  • npm run build — compiles; /dev renders the feature-request section
  • Not manually clicked through in a browser (sandbox has no browser), and the GitHub issue-creation call is only exercised against a mocked GitHubIssueClient — no live network call was made to actually create an issue anywhere.

🤖 Generated with Claude Code

…-issue

Adds FeatureRequest — a community-submitted plugin idea scoped to a repo,
upvoted via the existing like mechanism (targetType "feature_request", no new
voting table) — plus an admin-only conversion into a real GitHub issue via a
new write-side GitHubIssueClient. Conversion is idempotent (repeat calls don't
create duplicate issues) and gated by a configured username allowlist
(dpc.admin.usernames), not a broader roles system, since there's exactly one
admin action today.

New ideas enter the same backlog everything else lives in — this is intake,
not a second, parallel tracker.

Also extends ApiKeyAuthFilter's exempt-prefix list for the new bearer-token
writes, same as the #233 fix for /api/v1/claims.

Fourth and final phase of the dev-portal stack (builds on #233).
dmccoystephenson added a commit that referenced this pull request Jul 4, 2026
Replaces the single "Sort by" dropdown (which only covered the item list's
date/interest ordering) with proper clickable column-header sorting on both
tables:

- By repository: Repo, Issues, PRs, Oldest open item, Signal (severity —
  Stale sorts above Active).
- Open items: Item, Type, Opened, Interested.

First click sorts in whichever direction is usually useful for that column
(e.g. Oldest ascending puts the oldest item on top, Interested descending
puts the most-wanted on top); a second click on the same column flips it.
With no column selected, both tables keep their original order (largest
backlog first for repos, oldest-first for items) exactly as before.

Stacked on #234, alongside #235 (this supersedes its "Sort by" dropdown).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant