schedule-modal Component

Documentation for the scheduling modal that allows future-dated publish/unpublish/delete actions.

10/19/2026

3 min read

On this page

The schedule-modal component provides a user interface for scheduling future actions (publish, unpublish, delete) on collection entries.

Architecture

flowchart LR subgraph Trigger["Action Trigger"] MB[MultiButton] EA[EntryActions] end subgraph Modal["schedule-modal"] DI[Date Input] TI[Time Input] AS[Action Select] VL[Validation] end subgraph Response["Response Handler"] MS[modalState] CB[Callback] end Trigger -->|Open| Modal DI --> VL TI --> VL VL -->|Valid| CB CB --> MS MS -->|Close| Trigger

Features

Feature	Description
DateTime Selection	Separate date and time inputs for precision
Action Selection	Choose between publish, unpublish, or delete
Future Validation	Enforces scheduling for future dates only
Modal Integration	Uses `modalState` for dialog management
Accessible	ARIA labels and keyboard navigation

User Flow

sequenceDiagram
    participant U as User
    participant MB as MultiButton
    participant SM as schedule-modal
    participant MS as modalState
    participant API as Server

    U->>MB: Click Schedule
    MB->>MS: Open modal
    MS->>SM: Render form
    U->>SM: Select date/time/action
    SM->>SM: Validate (future date)
    U->>SM: Click Schedule
    SM->>MS: close(response)
    MS->>MB: Callback with data
    MB->>API: Schedule action

Known limitations

The modal returns { confirmed, date, action }, but the current callers persist only the date:

The selected action is not stored. Every scheduled job targets publish; scheduled unpublish and delete do not work.
Scheduling a new entry in create mode does not enqueue a job because no entry id exists yet. The entry is saved as schedule but never transitions.
Cancel Schedule clears local state only; it does not delete the already-created job, which still runs at its original time.
Re-saving a scheduled entry creates another job; jobs are not deduplicated.
The scheduled-jobs sweep does not provide draft-relation validation for collection entries: it scans content_nodes, while entries live in collection_<id> tables, and its relation matcher expects 24-hex ObjectIds while generated ids are UUIDv7.
The working status-transition scheduler path emits entry:update, not entry:publish.

Cache invalidation still happens after the scheduled update through the normal post-write pipeline; it is not conditional on relation validation.

Response Format

interface ScheduleResponse {
  confirmed: boolean;
  date: Date;
  action: "publish" | "unpublish" | "delete";
}

Usage

The modal is opened via modalState and returns a response object:

// Opening the modal
modalState.open({
  component: schedule - modal,
  props: {
    meta: { initialAction: "publish" },
  },
});

// Handling response (via modalState callback)
// { confirmed: true, date: Date, action: 'publish' }