Repository navigation
Redirect to dashboard after finalizing a live drive - #16
Merged
Merged
Conversation
Finalizing a live drive previously landed on the new drive's detail page; send the user to the main dashboard instead.
Async forms (end/finalize/cancel/etc.) were rendering the failure response's full HTML page (including inlined script contents and nav links) through a tag-stripping regex before alerting it, so a simple validation failure like a too-short drive surfaced as a wall of noise instead of the actual message. The client now asks for a JSON error body, and the server returns just the message when it does.
datetime-local inputs only carry minute precision, so a drive shorter than a minute renders identical start/end field values even though the server holds the true, more precise timestamps. The editor's client-side check treated that as "end before start" and quietly set a validity error on page load, so tapping Save did nothing with no visible feedback. Only block on an end that's genuinely before the start, and let the server's full-precision minimum-duration check (now reporting plainly, per the prior fix) be the real authority.
…hboard The finalize form now shows an inline warning as soon as the drive is (or would be) under the 30-second minimum, computed from the server's full-precision start/end timestamps rather than the minute-precision datetime-local inputs, so the driver sees the problem before tapping Save instead of only after. The 30-second threshold is now a shared constant (MINIMUM_DRIVE_SECONDS) instead of a duplicated literal. Finalizing a live drive now also flags the redirect with ?saved=1 so the dashboard can show a "Drive saved." banner; the query string is stripped from the URL bar right after render so a manual refresh doesn't keep re-showing it.
Correcting just the end (or just the start) time on the finalize form compared that whole-minute corrected value against the *other* side's raw, sub-minute-precision timestamp still held from the live drive. That could make a drive the editor displayed as a full minute long compute to only a few seconds, wrongly tripping the 30-second minimum no matter how much time the driver added. Once either side is corrected, round the uncorrected side to the minute too, so the length check matches what the editor shows. An untouched submission still checks the true elapsed time, so a genuinely too-short live drive is still caught.
The dashboard's post-save banner now reads "Xh YYm drive saved" and carries an "Edit drive" button linking straight to that drive's edit page, instead of a generic confirmation sentence. The finalize redirect now carries the saved drive's id (?saved=<id>) so the dashboard can look up its duration and build the edit link.
Rounding the untouched endpoint to the minute only when its sibling had been corrected meant editing one field could silently change how the other, untouched field's value was interpreted for the length check -- surprising, and not something the user asked for. Each side now always reads as its correction if given, otherwise its raw recorded time rounded to the minute, independent of what happened to the other side. This also means the check runs against the same values that get stored, so it can no longer be fooled into passing a duration that then fails to persist.
Add a regression test for the case that used to surface as "drive must have a positive duration": a raw span (e.g. :15 to :59) that clears the 30-second minimum but rounds down to a zero-minute record because it never crosses a minute boundary. The minimum-duration check now runs against the same rounded values that get stored, so this is caught with the same plain message as any other too-short drive, before it ever reaches record creation.
Editing a drive (e.g. from the post-save dashboard banner) only had a
Save button, with no way back out and no way to delete. Add a Cancel
link back to the drive's detail page and a Delete button matching the
detail page's existing confirmation, both scoped to edit mode only
(the new-drive form has neither, since there's nothing yet to discard
or delete).
Cancel only prompts ("Discard your changes to this drive?") if the
form actually differs from what was rendered; an untouched edit just
navigates straight back.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
/) instead of the new drive's detail page (/drives/{id})Test plan
pytest -m "not browser" --ignore=tests/test_browser.py(88 passed, 1 skipped)ruff check .ruff format --check .mypy🤖 Generated with Claude Code
Generated by Claude Code