targets has both a blue add button and also a + Add at the top. it should be empty until the +Add is clicked, then it should show a row that lets a user select a type of target, then upon selecting the target type and hitting next, it should have fields for the specific settings of that target type.
PRIORITY: an owner's direct request of 1 October, in the same tier as #367, #368 and #369: after the production path, ahead of the older backlog.
Definition of done, for the targets section of the per-webhook page:
There is exactly one add control, "+ Add" at the top. The separate blue add button is gone.
Until "+ Add" is clicked, no add form shows. The section lists only the existing targets, or an empty state.
Clicking "+ Add" shows one row with a choice of target type and a "Next" button.
After a type is picked and "Next" is pressed, the row shows only the fields for that type's settings. It saves as a target creation does today, with the same validation and errors. A way to cancel returns to the empty state.
It works with JavaScript as the page already uses it (Alpine.js, vendored per #345). Server-side validation stays the authority.
Tests cover the flow for every target type. Lands on next with an independent review, rebased onto 367's route change if that lands first.
model: opus-5-5
Owner's words (chat, 2026-10-01 ~19:00 UTC):
> targets has both a blue add button and also a + Add at the top. it should be empty until the +Add is clicked, then it should show a row that lets a user select a type of target, then upon selecting the target type and hitting next, it should have fields for the specific settings of that target type.
PRIORITY: an owner's direct request of 1 October, in the same tier as https://git.eeqj.de/sneak/webhooker/issues/367, https://git.eeqj.de/sneak/webhooker/issues/368 and https://git.eeqj.de/sneak/webhooker/issues/369: after the production path, ahead of the older backlog.
Definition of done, for the targets section of the per-webhook page:
- There is exactly one add control, "+ Add" at the top. The separate blue add button is gone.
- Until "+ Add" is clicked, no add form shows. The section lists only the existing targets, or an empty state.
- Clicking "+ Add" shows one row with a choice of target type and a "Next" button.
- After a type is picked and "Next" is pressed, the row shows only the fields for that type's settings. It saves as a target creation does today, with the same validation and errors. A way to cancel returns to the empty state.
- It works with JavaScript as the page already uses it (Alpine.js, vendored per https://git.eeqj.de/sneak/webhooker/issues/345). Server-side validation stays the authority.
- Tests cover the flow for every target type. Lands on `next` with an independent review, rebased onto 367's route change if that lands first.
model: opus-5-5
clawbot
self-assigned this 2026-10-01 21:00:17 +02:00
when overhauling the target add UX, remember that many targets don't need a URL - a database target doesn't need a URL field for example, it's nonsensitcal
This adds to the definition of done: each target type's form shows only the fields that type actually uses. A type that needs no URL (the database target, for one) shows no URL field, and the server neither requires nor stores one for it. The plan comment on this issue lists, per target type, the fields it shows. A test checks that the URL field is absent for every type that does not use it. If the current data model makes URL mandatory for every target, that is fixed in place (pre-1.0: no migration, no compatibility).
model: opus-5-5
Owner's addition (chat, 2026-10-01 ~19:02 UTC):
> when overhauling the target add UX, remember that many targets don't need a URL - a database target doesn't need a URL field for example, it's nonsensitcal
This adds to the definition of done: each target type's form shows only the fields that type actually uses. A type that needs no URL (the database target, for one) shows no URL field, and the server neither requires nor stores one for it. The plan comment on this issue lists, per target type, the fields it shows. A test checks that the URL field is absent for every type that does not use it. If the current data model makes URL mandatory for every target, that is fixed in place (pre-1.0: no migration, no compatibility).
model: opus-5-5
The owner's view of both add controls at once has a cause beyond the layout: the add form is meant to stay hidden until "+ Add" is clicked, but Alpine.js does not run under the page's security policy, so nothing hides it. That is #371, and this issue builds on its fix.
One "+ Add" at the top of the targets section; the separate blue button and the open form go. Until it is clicked, the section lists only the targets, or "No targets configured."
"+ Add" shows one row: a choice of target type (http, slack, database, log) and "Next". "Next" replaces the row with the name field and that type's own fields, a save button and "Cancel"; "Cancel" returns to the empty state. The steps run in the page, with no extra request, and the form posts to the same target-creation route as today.
The server stays the authority, with the same validation and errors. When it rejects a submission and renders the page again, the form comes back open on the chosen type, with the values entered and the error shown.
The entrypoints section's add control is not in this issue and stays as it is.
Tests: a handler test per target type for creation and for a rejected submission coming back on its type, and a headless browser check of the flow for every type.
Sequencing: after 371, and on top of #367's paths if that lands first; the change stays inside the targets section.
Model: opus-5-5
Plan.
The owner's view of both add controls at once has a cause beyond the layout: the add form is meant to stay hidden until "+ Add" is clicked, but Alpine.js does not run under the page's security policy, so nothing hides it. That is https://git.eeqj.de/sneak/webhooker/issues/371, and this issue builds on its fix.
- One "+ Add" at the top of the targets section; the separate blue button and the open form go. Until it is clicked, the section lists only the targets, or "No targets configured."
- "+ Add" shows one row: a choice of target type (`http`, `slack`, `database`, `log`) and "Next". "Next" replaces the row with the name field and that type's own fields, a save button and "Cancel"; "Cancel" returns to the empty state. The steps run in the page, with no extra request, and the form posts to the same target-creation route as today.
- The server stays the authority, with the same validation and errors. When it rejects a submission and renders the page again, the form comes back open on the chosen type, with the values entered and the error shown.
- The entrypoints section's add control is not in this issue and stays as it is.
- Tests: a handler test per target type for creation and for a rejected submission coming back on its type, and a headless browser check of the flow for every type.
- Sequencing: after 371, and on top of https://git.eeqj.de/sneak/webhooker/issues/367's paths if that lands first; the change stays inside the targets section.
Model: opus-5-5
Found again by the audit for #377, on current next: refusing an http target (a private address, a reserved header) or a database expiry answers with a bare text page, and the form and everything typed into it is lost. The slack type's add form has no retry field, although its edit page has one and the engine honours it; the per-type form should include it. Showing it in the target list is #395.
Model: opus-5-5
Found again by the audit for https://git.eeqj.de/sneak/webhooker/issues/377, on current `next`: refusing an `http` target (a private address, a reserved header) or a `database` expiry answers with a bare text page, and the form and everything typed into it is lost. The `slack` type's add form has no retry field, although its edit page has one and the engine honours it; the per-type form should include it. Showing it in the target list is https://git.eeqj.de/sneak/webhooker/issues/395.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Owner's words (chat, 2026-10-01 ~19:00 UTC):
PRIORITY: an owner's direct request of 1 October, in the same tier as #367, #368 and #369: after the production path, ahead of the older backlog.
Definition of done, for the targets section of the per-webhook page:
nextwith an independent review, rebased onto 367's route change if that lands first.model: opus-5-5
Owner's addition (chat, 2026-10-01 ~19:02 UTC):
This adds to the definition of done: each target type's form shows only the fields that type actually uses. A type that needs no URL (the database target, for one) shows no URL field, and the server neither requires nor stores one for it. The plan comment on this issue lists, per target type, the fields it shows. A test checks that the URL field is absent for every type that does not use it. If the current data model makes URL mandatory for every target, that is fixed in place (pre-1.0: no migration, no compatibility).
model: opus-5-5
Plan.
The owner's view of both add controls at once has a cause beyond the layout: the add form is meant to stay hidden until "+ Add" is clicked, but Alpine.js does not run under the page's security policy, so nothing hides it. That is #371, and this issue builds on its fix.
http,slack,database,log) and "Next". "Next" replaces the row with the name field and that type's own fields, a save button and "Cancel"; "Cancel" returns to the empty state. The steps run in the page, with no extra request, and the form posts to the same target-creation route as today.Model: opus-5-5
Found again by the audit for #377, on current
next: refusing anhttptarget (a private address, a reserved header) or adatabaseexpiry answers with a bare text page, and the form and everything typed into it is lost. Theslacktype's add form has no retry field, although its edit page has one and the engine honours it; the per-type form should include it. Showing it in the target list is #395.Model: opus-5-5