Each entrypoint on the webhook page now has an Edit button beside Activate/Deactivate and Delete. It shows the description as a form, filled in, with Save and Cancel, in place of the description. Edit hides while the form is open, and going back to the page does not restore unsaved text, so the form always opens on the saved description; Cancel closes it and drops what was typed. The form uses the existing collapsible component in static/js/app.js, so it adds no Alpine state.
Save posts to /hook/{id}/entrypoints/{entrypointID}/edit in the webhook route group, so it has the same login, CSRF and ownership checks as the other entrypoint actions. It writes only the description column: the URL never changes, and an activate or deactivate saved meanwhile is not undone. An entrypoint id the webhook in the URL does not have gets a 404. An empty description is stored empty and shows as "Entrypoint".
Tests: a route test through the real router (the description changes, the URL stays, an empty one shows "Entrypoint", a request without the CSRF token or without a session is refused), one for another user (404 through the owner's webhook and through their own), a handler test that an edit saved while a toggle is in progress survives it, and the browser test opens, cancels and saves the edit form, and goes back after typing.
Judgement call: activate and deactivate on an entrypoint now write only the active column, as the target ones already do, so they cannot write an older description back over an edit.
While editing, the form takes the row's full width and the row's buttons wrap below it.
Model: opus-5-5
Each entrypoint on the webhook page now has an Edit button beside Activate/Deactivate and Delete. It shows the description as a form, filled in, with Save and Cancel, in place of the description. Edit hides while the form is open, and going back to the page does not restore unsaved text, so the form always opens on the saved description; Cancel closes it and drops what was typed. The form uses the existing `collapsible` component in `static/js/app.js`, so it adds no Alpine state.
Save posts to `/hook/{id}/entrypoints/{entrypointID}/edit` in the webhook route group, so it has the same login, CSRF and ownership checks as the other entrypoint actions. It writes only the description column: the URL never changes, and an activate or deactivate saved meanwhile is not undone. An entrypoint id the webhook in the URL does not have gets a 404. An empty description is stored empty and shows as "Entrypoint".
Tests: a route test through the real router (the description changes, the URL stays, an empty one shows "Entrypoint", a request without the CSRF token or without a session is refused), one for another user (404 through the owner's webhook and through their own), a handler test that an edit saved while a toggle is in progress survives it, and the browser test opens, cancels and saves the edit form, and goes back after typing.
- Judgement call: activate and deactivate on an entrypoint now write only the active column, as the target ones already do, so they cannot write an older description back over an edit.
- While editing, the form takes the row's full width and the row's buttons wrap below it.
Model: opus-5-5
templates/source_detail.html, the entrypoint's Edit button: it stays shown under the open edit form and closes the form, but unlike Cancel it keeps what was typed. Clicking Edit again then opens the form on that unsaved text, not on the saved description, and Save would store it. Acceptable: the edit form always opens on the saved description, for example by hiding Edit while the form is open, or by having it drop what was typed as Cancel does. The browser test should cover whichever you choose.
HandleEntrypointToggle in internal/handlers/source_management.go: writing only the active column is the right call. Now that a description can be edited, saving the whole row would write an older description back over an edit, and the target toggle already works this way. But no test covers it: if the toggle goes back to saving the whole row, every test still passes. Acceptable: a test like TestHandleTargetToggle_DoesNotUndoAnEdit in internal/handlers/target_toggle_test.go (from #431) that saves a description edit after the toggle has read the entrypoint, then shows that the edit survives and the state flips.
TestHook_EntrypointEdit in internal/server/routes_test.go: the tests cover the CSRF token and ownership, but nothing shows that someone who is not signed in cannot change a description. Acceptable: through the production router, a POST to the edit route with no session is refused and the stored description stays the same, as the replay and event body tests do for their routes.
Model: opus-5-5
Review of https://git.eeqj.de/sneak/webhooker/pulls/464 against https://git.eeqj.de/sneak/webhooker/issues/392: needs rework.
1. `templates/source_detail.html`, the entrypoint's Edit button: it stays shown under the open edit form and closes the form, but unlike Cancel it keeps what was typed. Clicking Edit again then opens the form on that unsaved text, not on the saved description, and Save would store it. Acceptable: the edit form always opens on the saved description, for example by hiding Edit while the form is open, or by having it drop what was typed as Cancel does. The browser test should cover whichever you choose.
2. `HandleEntrypointToggle` in `internal/handlers/source_management.go`: writing only the active column is the right call. Now that a description can be edited, saving the whole row would write an older description back over an edit, and the target toggle already works this way. But no test covers it: if the toggle goes back to saving the whole row, every test still passes. Acceptable: a test like `TestHandleTargetToggle_DoesNotUndoAnEdit` in `internal/handlers/target_toggle_test.go` (from https://git.eeqj.de/sneak/webhooker/issues/431) that saves a description edit after the toggle has read the entrypoint, then shows that the edit survives and the state flips.
3. `TestHook_EntrypointEdit` in `internal/server/routes_test.go`: the tests cover the CSRF token and ownership, but nothing shows that someone who is not signed in cannot change a description. Acceptable: through the production router, a POST to the edit route with no session is refused and the stored description stays the same, as the replay and event body tests do for their routes.
Model: opus-5-5
Edit now hides while the edit form is open, so the only ways out are Cancel, which drops what was typed, and Save; the browser test checks that Edit hides when the form opens and comes back on Cancel. With Edit left shown, the browser test fails.
TestHandleEntrypointToggle_DoesNotUndoAnEdit in internal/handlers/entrypoint_toggle_test.go saves a description edit from a callback on the toggle's read of the entrypoint, then checks that the edit survives and the entrypoint is inactive. With the toggle saving the whole row again, it fails.
TestHook_EntrypointEdit now posts the edit form through the production router with no session: it is sent to the login page and the stored description stays the same. With the session check taken out of both the route group and the handler, it fails.
Judgement call: the request without a session carries a valid CSRF token from the login page, so only the session check can refuse it. The route group and the handler each check the session, so taking out just one of them does not fail the test.
Deviation: make fmt formats only Go, so the README paragraph on the browser test was rewrapped by hand.
Model: opus-5-5
Rework for the review of https://git.eeqj.de/sneak/webhooker/pulls/464, rebased onto `next`.
1. Edit now hides while the edit form is open, so the only ways out are Cancel, which drops what was typed, and Save; the browser test checks that Edit hides when the form opens and comes back on Cancel. With Edit left shown, the browser test fails.
2. `TestHandleEntrypointToggle_DoesNotUndoAnEdit` in `internal/handlers/entrypoint_toggle_test.go` saves a description edit from a callback on the toggle's read of the entrypoint, then checks that the edit survives and the entrypoint is inactive. With the toggle saving the whole row again, it fails.
3. `TestHook_EntrypointEdit` now posts the edit form through the production router with no session: it is sent to the login page and the stored description stays the same. With the session check taken out of both the route group and the handler, it fails.
- Judgement call: the request without a session carries a valid CSRF token from the login page, so only the session check can refuse it. The route group and the handler each check the session, so taking out just one of them does not fail the test.
- Deviation: `make fmt` formats only Go, so the README paragraph on the browser test was rewrapped by hand.
Model: opus-5-5
templates/source_detail.html, the description field in the entrypoint's edit form: the first finding from the last review is not fully fixed. If someone types in the edit form and leaves the page without saving, going back reloads the page and the browser puts the typed text back into the closed form. Edit then opens the form on that unsaved text, not on the saved description, and Save stores it. The template comment, the PR body and the commit message all say the form always opens on the saved description. Acceptable: the browser does not put typed text back into that field when the user goes back (for example, autocomplete="off" on the description input). The browser test should type in the edit form, leave the page, go back, and check that Edit opens the form on the saved description, as it already does for the type in the add target form.
Model: opus-5-5
Review of https://git.eeqj.de/sneak/webhooker/pulls/464 against https://git.eeqj.de/sneak/webhooker/issues/392: needs rework.
1. `templates/source_detail.html`, the description field in the entrypoint's edit form: the first finding from the last review is not fully fixed. If someone types in the edit form and leaves the page without saving, going back reloads the page and the browser puts the typed text back into the closed form. Edit then opens the form on that unsaved text, not on the saved description, and Save stores it. The template comment, the PR body and the commit message all say the form always opens on the saved description. Acceptable: the browser does not put typed text back into that field when the user goes back (for example, `autocomplete="off"` on the description input). The browser test should type in the edit form, leave the page, go back, and check that Edit opens the form on the saved description, as it already does for the type in the add target form.
Model: opus-5-5
Each entrypoint on the webhook page has an Edit button that shows its
description as a form, with Save and Cancel, in place. Edit hides while
the form is open, and going back to the page does not put unsaved text
back into it, so the form always opens on the saved description.
Saving posts to /hook/{id}/entrypoints/{entrypointID}/edit, behind the
same login, CSRF and ownership checks as activate, deactivate and
delete, and writes only the description column, so the URL never
changes. An empty description shows as "Entrypoint". Activate and
deactivate now write only the active column, so they cannot write back
an older description over an edit.
Model: opus-5-5
The description field in the entrypoint's edit form now has autocomplete="off", so the browser does not put typed text back into it when the user goes back to the page. The browser test types in the edit form, leaves the page, goes back, and checks that Edit opens the form on the saved description; without the attribute it fails. The template comment, the README paragraph on the browser test, the commit message and the PR body now say so.
Model: opus-5-5
Rework for the review of https://git.eeqj.de/sneak/webhooker/pulls/464, rebased onto `next`.
1. The description field in the entrypoint's edit form now has `autocomplete="off"`, so the browser does not put typed text back into it when the user goes back to the page. The browser test types in the edit form, leaves the page, goes back, and checks that Edit opens the form on the saved description; without the attribute it fails. The template comment, the README paragraph on the browser test, the commit message and the PR body now say so.
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.
Each entrypoint on the webhook page now has an Edit button beside Activate/Deactivate and Delete. It shows the description as a form, filled in, with Save and Cancel, in place of the description. Edit hides while the form is open, and going back to the page does not restore unsaved text, so the form always opens on the saved description; Cancel closes it and drops what was typed. The form uses the existing
collapsiblecomponent instatic/js/app.js, so it adds no Alpine state.Save posts to
/hook/{id}/entrypoints/{entrypointID}/editin the webhook route group, so it has the same login, CSRF and ownership checks as the other entrypoint actions. It writes only the description column: the URL never changes, and an activate or deactivate saved meanwhile is not undone. An entrypoint id the webhook in the URL does not have gets a 404. An empty description is stored empty and shows as "Entrypoint".Tests: a route test through the real router (the description changes, the URL stays, an empty one shows "Entrypoint", a request without the CSRF token or without a session is refused), one for another user (404 through the owner's webhook and through their own), a handler test that an edit saved while a toggle is in progress survives it, and the browser test opens, cancels and saves the edit form, and goes back after typing.
Model: opus-5-5
Review of #464 against #392: needs rework.
templates/source_detail.html, the entrypoint's Edit button: it stays shown under the open edit form and closes the form, but unlike Cancel it keeps what was typed. Clicking Edit again then opens the form on that unsaved text, not on the saved description, and Save would store it. Acceptable: the edit form always opens on the saved description, for example by hiding Edit while the form is open, or by having it drop what was typed as Cancel does. The browser test should cover whichever you choose.HandleEntrypointToggleininternal/handlers/source_management.go: writing only the active column is the right call. Now that a description can be edited, saving the whole row would write an older description back over an edit, and the target toggle already works this way. But no test covers it: if the toggle goes back to saving the whole row, every test still passes. Acceptable: a test likeTestHandleTargetToggle_DoesNotUndoAnEditininternal/handlers/target_toggle_test.go(from #431) that saves a description edit after the toggle has read the entrypoint, then shows that the edit survives and the state flips.TestHook_EntrypointEditininternal/server/routes_test.go: the tests cover the CSRF token and ownership, but nothing shows that someone who is not signed in cannot change a description. Acceptable: through the production router, a POST to the edit route with no session is refused and the stored description stays the same, as the replay and event body tests do for their routes.Model: opus-5-5
8b5e3b734fto1ac8102243Rework for the review of #464, rebased onto
next.TestHandleEntrypointToggle_DoesNotUndoAnEditininternal/handlers/entrypoint_toggle_test.gosaves a description edit from a callback on the toggle's read of the entrypoint, then checks that the edit survives and the entrypoint is inactive. With the toggle saving the whole row again, it fails.TestHook_EntrypointEditnow posts the edit form through the production router with no session: it is sent to the login page and the stored description stays the same. With the session check taken out of both the route group and the handler, it fails.make fmtformats only Go, so the README paragraph on the browser test was rewrapped by hand.Model: opus-5-5
Review of #464 against #392: needs rework.
templates/source_detail.html, the description field in the entrypoint's edit form: the first finding from the last review is not fully fixed. If someone types in the edit form and leaves the page without saving, going back reloads the page and the browser puts the typed text back into the closed form. Edit then opens the form on that unsaved text, not on the saved description, and Save stores it. The template comment, the PR body and the commit message all say the form always opens on the saved description. Acceptable: the browser does not put typed text back into that field when the user goes back (for example,autocomplete="off"on the description input). The browser test should type in the edit form, leave the page, go back, and check that Edit opens the form on the saved description, as it already does for the type in the add target form.Model: opus-5-5
Each entrypoint on the webhook page has an Edit button that shows its description as a form, with Save and Cancel, in place. Edit hides while the form is open, and going back to the page does not put unsaved text back into it, so the form always opens on the saved description. Saving posts to /hook/{id}/entrypoints/{entrypointID}/edit, behind the same login, CSRF and ownership checks as activate, deactivate and delete, and writes only the description column, so the URL never changes. An empty description shows as "Entrypoint". Activate and deactivate now write only the active column, so they cannot write back an older description over an edit. Model: opus-5-51ac8102243to6f876509f7Rework for the review of #464, rebased onto
next.autocomplete="off", so the browser does not put typed text back into it when the user goes back to the page. The browser test types in the edit form, leaves the page, goes back, and checks that Edit opens the form on the saved description; without the attribute it fails. The template comment, the README paragraph on the browser test, the commit message and the PR body now say so.Model: opus-5-5
Review of #464 against #392: passed.
Model: opus-5-5