expand the new webhook page which currently only has name description and retention. add a field for an http target url, if filled, add an http target. add a checkbox for archiving, and if checked, allow the user to select archive pruning from a popup list (never, 1h, 12h, 24h, 30d, 90d, 365d), which of course adds an archive target as well.
PRIORITY: an owner's direct request of 1 October, in the tier of #367 to #372: after the production path, ahead of the older backlog.
Related: 367 moves this page (to /hooks/new in the manager's plan), and #370 reworks adding a target per type. Reuse 370's per-type target creation and validation, not a second copy.
Definition of done, for the new-webhook page:
It keeps name, description and retention, and adds:
an optional HTTP target URL field. When it is filled, creating the webhook also creates an HTTP target with that URL. When it is empty, no HTTP target is created;
an "archive" checkbox. When it is checked, a dropdown offers archive pruning: never, 1h, 12h, 24h, 30d, 90d, 365d. Creating the webhook then also creates an archive target with that pruning. When it is unchecked, the dropdown is hidden and no archive target is created.
The webhook and its targets are created together, or not at all. An invalid URL rejects the whole form with a clear error and keeps the entered values.
The plan comment on this issue says which existing target type is the "archive target", and how its pruning setting maps onto it. If there is no such setting today, it is added in place (pre-1.0: no migration, no compatibility).
Tests cover every combination: URL filled or empty, archive on with each pruning choice, archive off, and an invalid URL. Lands on next with an independent review, sequenced with 367 and 370.
model: opus-5-5
Owner's words (chat, 2026-10-01 ~19:12 UTC):
> expand the new webhook page which currently only has name description and retention. add a field for an http target url, if filled, add an http target. add a checkbox for archiving, and if checked, allow the user to select archive pruning from a popup list (never, 1h, 12h, 24h, 30d, 90d, 365d), which of course adds an archive target as well.
PRIORITY: an owner's direct request of 1 October, in the tier of https://git.eeqj.de/sneak/webhooker/issues/367 to https://git.eeqj.de/sneak/webhooker/issues/372: after the production path, ahead of the older backlog.
Related: 367 moves this page (to `/hooks/new` in the manager's plan), and https://git.eeqj.de/sneak/webhooker/issues/370 reworks adding a target per type. Reuse 370's per-type target creation and validation, not a second copy.
Definition of done, for the new-webhook page:
- It keeps name, description and retention, and adds:
- an optional HTTP target URL field. When it is filled, creating the webhook also creates an HTTP target with that URL. When it is empty, no HTTP target is created;
- an "archive" checkbox. When it is checked, a dropdown offers archive pruning: never, 1h, 12h, 24h, 30d, 90d, 365d. Creating the webhook then also creates an archive target with that pruning. When it is unchecked, the dropdown is hidden and no archive target is created.
- The webhook and its targets are created together, or not at all. An invalid URL rejects the whole form with a clear error and keeps the entered values.
- The plan comment on this issue says which existing target type is the "archive target", and how its pruning setting maps onto it. If there is no such setting today, it is added in place (pre-1.0: no migration, no compatibility).
- Tests cover every combination: URL filled or empty, archive on with each pruning choice, archive off, and an invalid URL. Lands on `next` with an independent review, sequenced with 367 and 370.
model: opus-5-5
clawbot
self-assigned this 2026-10-01 21:12:41 +02:00
The archive target is the existing database target type, and its pruning is that type's existing expiry setting (a duration, or never). The dropdown maps never to never, 1h to 1h, 12h to 12h, 24h to 24h, 30d to 720h, 90d to 2160h and 365d to 8760h. No schema change.
The form posts once. The handler validates the webhook's fields and each requested target with the same per-type validation that #370's add flow uses, then creates the webhook, its entrypoint (as today) and the targets in one transaction. Any error rejects the whole form, which comes back with the values entered and the error shown.
The new targets are named "HTTP" and "Archive"; they can be renamed on the webhook page like any other target.
Sequencing: after #367 (the page moves to /hooks/new) and 370.
Model: opus-5-5
Plan.
- **The archive target** is the existing `database` target type, and its pruning is that type's existing `expiry` setting (a duration, or `never`). The dropdown maps never to `never`, 1h to `1h`, 12h to `12h`, 24h to `24h`, 30d to `720h`, 90d to `2160h` and 365d to `8760h`. No schema change.
- The form posts once. The handler validates the webhook's fields and each requested target with the same per-type validation that https://git.eeqj.de/sneak/webhooker/issues/370's add flow uses, then creates the webhook, its entrypoint (as today) and the targets in one transaction. Any error rejects the whole form, which comes back with the values entered and the error shown.
- The new targets are named "HTTP" and "Archive"; they can be renamed on the webhook page like any other target.
- Sequencing: after https://git.eeqj.de/sneak/webhooker/issues/367 (the page moves to `/hooks/new`) and 370.
Model: opus-5-5
Found again by the audit for #377, on current next: when the new-webhook page rejects a retention value (for example -5), the form comes back with the retention field reset to the default of 30, so the operator no longer sees what was refused. This issue's "keeps the entered values" should cover retention too.
Model: opus-5-5
Found again by the audit for https://git.eeqj.de/sneak/webhooker/issues/377, on current `next`: when the new-webhook page rejects a retention value (for example -5), the form comes back with the retention field reset to the default of 30, so the operator no longer sees what was refused. This issue's "keeps the entered values" should cover retention too.
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:12 UTC):
PRIORITY: an owner's direct request of 1 October, in the tier of #367 to #372: after the production path, ahead of the older backlog.
Related: 367 moves this page (to
/hooks/newin the manager's plan), and #370 reworks adding a target per type. Reuse 370's per-type target creation and validation, not a second copy.Definition of done, for the new-webhook page:
nextwith an independent review, sequenced with 367 and 370.model: opus-5-5
Plan.
databasetarget type, and its pruning is that type's existingexpirysetting (a duration, ornever). The dropdown maps never tonever, 1h to1h, 12h to12h, 24h to24h, 30d to720h, 90d to2160hand 365d to8760h. No schema change./hooks/new) and 370.Model: opus-5-5
Found again by the audit for #377, on current
next: when the new-webhook page rejects a retention value (for example -5), the form comes back with the retention field reset to the default of 30, so the operator no longer sees what was refused. This issue's "keeps the entered values" should cover retention too.Model: opus-5-5