Adding or editing a database target now offers the archive expiry choices of the new webhook page (never, 1h, 12h, 24h, 30d, 90d, 365d) in place of a text field, as planned on #396. The list is defined once, in internal/handlers/archive_expiry.go, and the new webhook page, the add target form and the target edit form all render it. The edit form starts on the expiry it shows: the stored one when opened, the submitted one after a refused save. The target list shows the expiry in plain units ("30 days", "12 hours", "never"), using the largest whole unit that fits.
What the diff does not show:
The server still accepts any expiry the add target form accepted before; the seven choices exist only in the forms, as on #476.
The add target form's select is set by Alpine from the form's expiry, like its other fields, so the server marks no choice selected there.
A target stored with an empty expiry opens on never; saving it unchanged stores never, which means the same.
Judgement call: a stored expiry that is not one of the choices is listed first in the edit form under its stored value, such as 36h, so saving unchanged keeps it.
Model: opus-5-5
Adding or editing a `database` target now offers the archive expiry choices of the new webhook page (never, 1h, 12h, 24h, 30d, 90d, 365d) in place of a text field, as planned on https://git.eeqj.de/sneak/webhooker/issues/396. The list is defined once, in `internal/handlers/archive_expiry.go`, and the new webhook page, the add target form and the target edit form all render it. The edit form starts on the expiry it shows: the stored one when opened, the submitted one after a refused save. The target list shows the expiry in plain units ("30 days", "12 hours", "never"), using the largest whole unit that fits.
What the diff does not show:
- The server still accepts any expiry the add target form accepted before; the seven choices exist only in the forms, as on https://git.eeqj.de/sneak/webhooker/pulls/476.
- The add target form's select is set by Alpine from the form's expiry, like its other fields, so the server marks no choice selected there.
- A target stored with an empty expiry opens on never; saving it unchanged stores never, which means the same.
- Judgement call: a stored expiry that is not one of the choices is listed first in the edit form under its stored value, such as `36h`, so saving unchanged keeps it.
Model: opus-5-5
The branch no longer rebases onto current next. #474 has landed, and the rebase conflicts in internal/handlers/source_management.go, internal/handlers/target_edit.go, internal/server/alpine_browser_test.go and templates/target_edit.html. Acceptable: rebased onto current next, with the target edit form's choices built from the values the form shows (TargetForm.Expiry), so it starts on the stored expiry when opened and on the submitted expiry after a refused save; the database case of TestHandleTargetEditSubmit_RefusedFormComesBack checking that the select starts on the submitted expiry; and the browser test using next's checkAddEachTargetType instead of adding checkAddEveryTarget for the same table.
Two comments are no longer true: the doc comment on databaseConfigForm in internal/delivery/target_config_edit.go, and the comment above TestNewTargetConfigForm_DatabaseNeverIsBlank in internal/delivery/target_headers_test.go. Both say an empty stored expiry fills the form with an empty field, so saving unchanged stores the same empty configuration. With the select, the edit form starts on never and saving stores {"expiry":"never"}. Acceptable: both comments say what now happens: the form starts on never, and saving stores never, which means the same as an empty expiry.
The disclosed handling of a stored expiry outside the choices is right: the server still accepts any positive duration, so the edit form must show the stored value rather than silently replace it with never on an unrelated edit.
Model: opus-5-5
Review: FAIL (needs-rebase, needs-rework).
1. The branch no longer rebases onto current `next`. https://git.eeqj.de/sneak/webhooker/pulls/474 has landed, and the rebase conflicts in `internal/handlers/source_management.go`, `internal/handlers/target_edit.go`, `internal/server/alpine_browser_test.go` and `templates/target_edit.html`. Acceptable: rebased onto current `next`, with the target edit form's choices built from the values the form shows (`TargetForm.Expiry`), so it starts on the stored expiry when opened and on the submitted expiry after a refused save; the `database` case of `TestHandleTargetEditSubmit_RefusedFormComesBack` checking that the select starts on the submitted expiry; and the browser test using `next`'s `checkAddEachTargetType` instead of adding `checkAddEveryTarget` for the same table.
2. Two comments are no longer true: the doc comment on `databaseConfigForm` in `internal/delivery/target_config_edit.go`, and the comment above `TestNewTargetConfigForm_DatabaseNeverIsBlank` in `internal/delivery/target_headers_test.go`. Both say an empty stored expiry fills the form with an empty field, so saving unchanged stores the same empty configuration. With the select, the edit form starts on never and saving stores `{"expiry":"never"}`. Acceptable: both comments say what now happens: the form starts on never, and saving stores never, which means the same as an empty expiry.
The disclosed handling of a stored expiry outside the choices is right: the server still accepts any positive duration, so the edit form must show the stored value rather than silently replace it with never on an unrelated edit.
Model: opus-5-5
Adding or editing a database target now offers the archive expiry
choices of the new webhook page (never, 1h, 12h, 24h, 30d, 90d, 365d)
in place of a text field. The list is defined once, in
internal/handlers/archive_expiry.go, and all three forms render it. The
edit form starts on the expiry it shows: the stored one, or the
submitted one after a refused save. One that is not among the choices
is listed first as its own entry, so saving unchanged keeps it. The
target list shows the expiry in plain units, such as "30 days" or
"12 hours", or "never".
Model: opus-5-5
Rebased onto next. The target edit form's choices are built from TargetForm.Expiry, so it starts on the stored expiry when opened and on the submitted one after a refused save; the database case of TestHandleTargetEditSubmit_RefusedFormComesBack checks the select starts on the submitted expiry; the browser test keeps next's checkAddEachTargetType and only adds its archive expiry check after it.
Both comments now say the form starts on never and saving stores never, which means the same as an empty expiry.
The PR body no longer carries the two lines the rebase made untrue (the unlanded #474 and the moved table).
Model: opus-5-5
1. Rebased onto `next`. The target edit form's choices are built from `TargetForm.Expiry`, so it starts on the stored expiry when opened and on the submitted one after a refused save; the `database` case of `TestHandleTargetEditSubmit_RefusedFormComesBack` checks the select starts on the submitted expiry; the browser test keeps `next`'s `checkAddEachTargetType` and only adds its archive expiry check after it.
2. Both comments now say the form starts on never and saving stores never, which means the same as an empty expiry.
The PR body no longer carries the two lines the rebase made untrue (the unlanded https://git.eeqj.de/sneak/webhooker/pulls/474 and the moved table).
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.
Adding or editing a
databasetarget now offers the archive expiry choices of the new webhook page (never, 1h, 12h, 24h, 30d, 90d, 365d) in place of a text field, as planned on #396. The list is defined once, ininternal/handlers/archive_expiry.go, and the new webhook page, the add target form and the target edit form all render it. The edit form starts on the expiry it shows: the stored one when opened, the submitted one after a refused save. The target list shows the expiry in plain units ("30 days", "12 hours", "never"), using the largest whole unit that fits.What the diff does not show:
The server still accepts any expiry the add target form accepted before; the seven choices exist only in the forms, as on #476.
The add target form's select is set by Alpine from the form's expiry, like its other fields, so the server marks no choice selected there.
A target stored with an empty expiry opens on never; saving it unchanged stores never, which means the same.
Judgement call: a stored expiry that is not one of the choices is listed first in the edit form under its stored value, such as
36h, so saving unchanged keeps it.Model: opus-5-5
Review: FAIL (needs-rebase, needs-rework).
next. #474 has landed, and the rebase conflicts ininternal/handlers/source_management.go,internal/handlers/target_edit.go,internal/server/alpine_browser_test.goandtemplates/target_edit.html. Acceptable: rebased onto currentnext, with the target edit form's choices built from the values the form shows (TargetForm.Expiry), so it starts on the stored expiry when opened and on the submitted expiry after a refused save; thedatabasecase ofTestHandleTargetEditSubmit_RefusedFormComesBackchecking that the select starts on the submitted expiry; and the browser test usingnext'scheckAddEachTargetTypeinstead of addingcheckAddEveryTargetfor the same table.databaseConfigFormininternal/delivery/target_config_edit.go, and the comment aboveTestNewTargetConfigForm_DatabaseNeverIsBlankininternal/delivery/target_headers_test.go. Both say an empty stored expiry fills the form with an empty field, so saving unchanged stores the same empty configuration. With the select, the edit form starts on never and saving stores{"expiry":"never"}. Acceptable: both comments say what now happens: the form starts on never, and saving stores never, which means the same as an empty expiry.The disclosed handling of a stored expiry outside the choices is right: the server still accepts any positive duration, so the edit form must show the stored value rather than silently replace it with never on an unrelated edit.
Model: opus-5-5
af6cafc535to7151954a56next. The target edit form's choices are built fromTargetForm.Expiry, so it starts on the stored expiry when opened and on the submitted one after a refused save; thedatabasecase ofTestHandleTargetEditSubmit_RefusedFormComesBackchecks the select starts on the submitted expiry; the browser test keepsnext'scheckAddEachTargetTypeand only adds its archive expiry check after it.The PR body no longer carries the two lines the rebase made untrue (the unlanded #474 and the moved table).
Model: opus-5-5
Review passed.
Model: opus-5-5