#20368: feat(cron): add UI edit flow for existing scheduled jobs

# feat(cron): add UI edit flow for existing scheduled jobs ## Summary Describe the problem and fix in 2–5 bullets: - Problem: Unable to edit old cron jobs easily - Why it matters: Fix mistakes and adjust schedules/commands without deleting/recreating jobs - What changed: UI — added an Edit flow for existing cron jobs (edit button, modal/inline form, validation, save/cancel) and wired it to the existing cron update endpoint so changes persist - What did NOT change (scope boundary): Backend scheduling engine and cron execution logic; no database schema changes; no new auth scopes ## Change Type (select all) - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [ ] Integrations - [ ] API / contracts - [x] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes # - Related # ## User-visible / Behavior Changes - Users can now edit existing cron jobs from the Cron list view: - An Edit action is available on each cron entry. - Edit opens a modal (or inline form) pre-populated with the job's fields (schedule/expression, command/action, description, timezone where applicable). - Client-side validation for cron expression and required fields is shown inline. - Save sends an update (PATCH/PUT) to the existing cron API endpoint and updates the UI in-place. - Cancel closes the editor without making any changes. - No change to cron execution semantics or scheduling engine behavior. ## Security Impact (required) - New permissions/capabilities? (No) - Secrets/tokens handling changed? (No) - New/changed network calls? (Yes — UI issues an update (PATCH/PUT) request to the existing cron API endpoint; no new endpoints added.) - Command/tool execution surface changed? (No) - Data access scope changed? (No) - If any `Yes`, explain risk + mitigation: - Risk: A malicious UI or user could attempt to change a cron to run an unsafe command. Mitigation: existing server-side authorization and validation remain; the UI only calls the existing update endpoint which enforces permissions and server validation. Client-side validation reduces accidental invalid changes; server still rejects unauthorized/invalid updates. ## Repro + Verification ### Environment - OS: macOS / Windows / Linux (tested on macOS) - Runtime/container: Local dev server (Node / web frontend) - Model/provider: N/A - Integration/channel (if any): Cron scheduler service (existing) - Relevant config (redacted): none ### Steps 1. Open the app and navigate to Cron / Scheduled Jobs. 2. Create a new cron job (or pick an existing one). 3. Click the "Edit" button on the cron entry. 4. Update fields (e.g., change schedule expression, command, description). 5. Click "Save". 6. Observe the cron list updates in-place and a success toast/notification is shown. 7. Verify the change persisted (refresh the page or check backend API: GET /cron/:id shows updated values). 8. Optionally, verify the schedule takes effect at the next run (or check job metadata in scheduler). ### Expected - The edited values are validated, accepted by the server, stored, and reflected in the UI. - No duplicate cron entries are created; the existing job is updated. ### Actual - Previously: Editing existing cron jobs was not possible (had to delete and recreate). - Now: Edit flow works as expected; changes persist. ## Evidence Attach at least one: - [ ] Failing test/log before + passing after - [ ] Trace/log snippets - [x] Screenshot/recording (attach in PR) - [ ] Perf numbers (if relevant) (Attach screenshot of the Edit modal and a successful update toast in the PR) ## Human Verification (required) What you personally verified (not just CI), and how: - Verified scenarios: - Edited schedule expression and saved; change persisted (verified via page refresh and GET /cron/:id). - Edited description and command fields; UI reflects updates immediately after save. - Cancel closes modal without persisting changes. - Client-side validation prevents obviously invalid cron expressions and shows errors. - Edge cases checked: - Empty required fields produce inline validation messages. - Updating with the same values behaves idempotently (no duplicate entries). - What you did **not** verify: - Scheduler runtime behavior across long-running production workloads (only manual/local verification). - Cross-device UI layout regressions in every supported platform. ## Compatibility / Migration - Backward compatible? (Yes) - Config/env changes? (No) - Migration needed? (No) - If yes, exact upgrade steps: N/A ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: - Revert the feature commit/PR or remove the Edit action from the UI. - Files/config to restore: - Revert the edited UI component files (cron list, edit modal/form, related TypeScript files). - Known bad symptoms reviewers should watch for: - Update requests returning 4xx/5xx consistently after edits (indicates API mismatch or validation issue). - Duplicate cron entries created instead of updating (indicates client is POSTing instead of PATCH). - UI not reflecting saved changes (state update bug). ## Risks and Mitigations - Risk: Client sends malformed cron expressions causing server rejections. - Mitigation: Add client-side validation and show server error messages; server still enforces validation and returns helpful errors. - Risk: UI code accidentally creates new cron entries instead of updating existing ones. - Mitigation: Confirm calls use the update endpoint (PATCH/PUT /cron/:id) and add tests to assert update semantics. - Risk: Permission checks bypassed on client (users see edit button but are not allowed). - Mitigation: Server enforces auth/authorization; hide edit action in UI for unauthorized users based on current user permissions. - Risk: UX regressions in list rendering after update. - Mitigation: Update component state immutably and add an E2E test to cover edit -> save -> list update flow. --- <img width="695" height="314" alt="image" src="https://github.com/user-attachments/assets/266d016a-30f6-4ee7-ba52-7ecfce3b5e2e" /> <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR adds an inline Edit flow for existing cron jobs in the UI. Clicking "Edit" on a job populates the existing "New Job" form with the job's fields, changes the submit button to "Save changes", and routes the save through `cron.update` instead of `cron.add`. A Cancel button exits editing mode. - The `CronState.cronEditingId` field is declared as required (`string | null`) in the controller but optional (`?: string | null`) in `AppViewState`, and is never initialized in `app.ts` — this is a type inconsistency that should also cause TypeScript errors in the test file where `createState` omits the field. - `cancelEditCron` only partially resets the form (clearing name, description, and payload text), leaving schedule, agent, session target, and other fields populated with values from the edited job. A user who cancels editing and then submits the form would unknowingly create a new job with those stale values. - Minor: redundant ternary on `everyUnit` (both branches return `"minutes"`) and the card title still reads "New Job" during editing. <h3>Confidence Score: 3/5</h3> - Functional but has a type inconsistency and an incomplete form-reset on cancel that could cause confusing UX. - The core edit → save flow works correctly at runtime and the view changes are clean. However, the type mismatch between `CronState` and `AppViewState` for `cronEditingId` needs reconciliation (and will likely break the test under strict TypeScript), and the incomplete reset in `cancelEditCron` could lead users to accidentally create jobs with stale field values. - `ui/src/ui/controllers/cron.ts` needs attention for the type mismatch, incomplete cancel reset, and missing initialization in `app.ts`. _{Last reviewed commit: 5d33ee2} <!-- greptile_other_comments_section --> _{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!} <!-- /greptile_comment -->